Hacker News Reader

Comment by xyzzy_plugh | Hacker News Reader

What surprise is that? It would appear that no one will be surprised because the scenario necessary is never actually used anywhere. It doesn't exist.

For a change to be breaking it needs the potential to be able to break. As the potential approaches zero, so too does the coefficient of breakage.

View on HN

One surprise is that the following loop will print false (now it prints true).

    for i, p := 0, (*int)(nil); p == nil; print(p == &i) {
        p = &i
    }

Another surprise is that the value a in the following loop will be duplicated twice in each loop step (now it never gets duplicated).

    func foo(constFunc func(*[100000]int)) {
        for a, i := [100000]int{}, 0; i < len(a); i++ {
            constFunc(&a)
        }
    }

That first example seems rather artificial; I can't recall I've ever had to do anything like that. What are real-world use cases? That second example seems like a rather convoluted way of looping 100000 times.

They are just demonstration code. The alike code in production certainly is different.

What would that look like then? How often is such code written?

Obviously you can write it like that, my point is that it's not clear to me people actually are writing code like that. "If a footgun is never encountered then is it really a footgun?"

This is not a problem about frequency. This is a problem about possible or not. Language design is a serious thing.

Every language makes it possible to do something potentially unexpected, which is also rather subjective because different people have different expectations. None of your examples are "broken" or exhibit inherently undesired behaviour. So it's very much about frequency: how often do people expect A? And how often do they expect B?

Your logic is so weird. Done here. :)

There is no alike code in production, which is obvious if you read the proposal in good faith. If you can find a real world use case that is impacted, the authors are keen to understand it.

The examples you share are in the proposal discussion, so there is little value in rehashing your apparently bad-faith argument here. It's not a breaking change if nothing breaks.

Go is and has always strived to be pragmatic. This is an incredibly pragmatic approach to solving a real problem. Being pedantic about this actually breaking a theoretical program which either makes no sense or doesn't exist does not add value to a proposal which already addresses this concept very well from the onset.

Reply on news.ycombinator.com