TIL that "nil" is not a reserved word in #golang, and this prints '1':```package mainconst nil = 1func main() { print(nil)}```What is this, #PHP in a trench coat?
-
@anderseknert Rationale and discussion on this here:
-
@anderseknert Rationale and discussion on this here:
@stahlbrandt @anderseknert what a stereotypical set of responses from the go creators, oh my god
It's like they are intentionally obtusely pretending to not understand the rationale behind the question
And think disallowing var true = false is a waste of resources because one could simply define var True = false, which isn't a good reason at all
Predeclared identifiers have a standard meaning, shadowing them to something else is bad, their commentary is wack
"but the rule is so simple"
-
@stahlbrandt @anderseknert what a stereotypical set of responses from the go creators, oh my god
It's like they are intentionally obtusely pretending to not understand the rationale behind the question
And think disallowing var true = false is a waste of resources because one could simply define var True = false, which isn't a good reason at all
Predeclared identifiers have a standard meaning, shadowing them to something else is bad, their commentary is wack
"but the rule is so simple"
@danvolchek @stahlbrandt agreed. Having read many threads like that from the past, I’d say that was a pattern. I’m not involved in enough in current development to know if that’s still the case, but FWIW the few times where I’ve interacted with Go devs recently they’ve all been super helpful. I hope that is the current pattern
-
R AodeRelay shared this topic
