@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.

Hi all.

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 uint8(255) + uint8(1) = uint(0) it doesn't mean I'll necessarily use that. But if I rely on that feature and it changes from Go 1.6 to Go 1.7 because the compiler / runtime changed then this will become a problem.

Thank you.

@dlsniper If it helps (for now), I can guarantee you that we are not going to change how 2's complement arithmetic is used in Go.