Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
spec: clarification for the language used in the language specifications #14558
I'm not a native English speaker so please bare with me.
While looking at the documentation for https://golang.org/ref/spec#Integer_overflow I've realized that the sentence:
I can read this as: for now one can assume the
Then based on the discussion I've had on this topic, I've realized that there are other points as well in the language specifications which are ambiguous. For example
As there are 144
Thank you for your consideration.
I think "programs may rely on wrap around" is correct. A program may or may not use the wrap around feature, and we certainly don't want to say a program have to (must) use the wrap around. "may disallow NUL" is also correct. We don't require each tool to always reject NUL characters, but the fact that some tools might reject NUL characters means you shouldn't use NUL characters in programs if you want to stay compatible with all implementations.
@dlsniper -- "May" doesn't only refer to optional features because the context isn't always "implementations may."
Even the text of RFC 2119 itself uses 'may' to refer to, e.g. how security issues "may be" tricky (and trickiness certainly isn't an optional feature; the sentence is just saying security issues turn out tricky sometimes). In RFCs, you sometimes see the distinction between the RFC 2119 use and others in some uses of the key words being capitalized.
In your example, and most other uses when I search the spec, "may" refers to what your program may do, not something a Go implementer may choose whether or not to do. Your program may rely on integer wraparound, omit most semicolons, use newlines in backtick-delimited raw strings, and so on. When your programs may use a feature, all compilers must implement it, no ambiguity. (If compilers didn't all have it, you couldn't rely on it, right?) There's a "may" because, as minux said, it would be wrong to say every Go program has to use every feature.
"Implementation restriction" refers to explicitly allowed limitations that a compiler can have, i.e. permitted variations. For example, compilers can choke on NUL bytes in source if they want to. So it's the reverse of how you were parsing it in the comment -- "may" on its own does not mean there can be inter-compiler variation, "implementation restriction" means there can be.
(Implementation restrictions don't take up much of the spec; more commonly, when a topic (the type of garbage collector, say) is implementation-dependent, the spec just doesn't discuss it at all.)
I hope that helps parse the spec. It's hard to say what would clarify it. I don't think capitalizing the few uses that refer to implementation variations would help much, and it just seems inevitable you have to think "what may do X?" when you see the word "may."
@dlsniper Point taken. Implementation restrictions do pose a certain problem because if a compiler (say the default compiler) has those restrictions; effectively it means that programs must fit within those restrictions (it's not like there's a lot of alternative implementations).
For instance, the NUL byte restriction is really not important for Go per se, and in fact it costs an extra test for each source byte read by the compiler. It's there to prevent trouble with other tools which (historically) may have had trouble dealing with NUL bytes.
We will have a fresh look at this when we get to it. This is not urgent.
I agree, this is definitely not a high priority issue. However it would help to better understand some of the aspects of what's defined as an expected behavior are actually mandatory and some aspects can be optional.
Please don't take those two examples only, I've quickly took them to prove a point.
And, to clarify this, it's not about the programs the end-users of the language write but rather what guarantees/expectations the language/compiler/runtime set/provide. To give an example: just because I know that in the current gc