4 ms·
They are just demonstration code. The alike code in production certainly is different.
by tapirl 3y ago
They are just demonstration code. The alike code in production certainly is different.
- arp242 3y agoWhat 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?"
- tapirl 3y agoThis is not a problem about frequency. This is a problem about possible or not. Language design is a serious thing.
- arp242 3y agoEvery 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?
- tapirl 3y agoYour logic is so weird. Done here. :)
- xyzzy_plugh 3y agoThere 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.