Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: clarification for the language used in the language specifications #14558

Open
dlsniper opened this issue Feb 29, 2016 · 5 comments

Comments

@dlsniper
Copy link
Contributor

commented Feb 29, 2016

Hi,

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: Loosely speaking, these unsigned integer operations discard high bits upon overflow, and programs may rely on "wrap around". currently leaves room for interpretation.

I can read this as: for now one can assume the wrap around will happen but it might be changed in the future. Or I can read this as wrap around will always be present (in Go 1.x).

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 Implementation restriction: For compatibility with other tools, a compiler may disallow the NUL character (U+0000) in the source text. sounds awful when you think of a limitation, Implementation restriction, and a may, optional, are involved. I've interpreted that as [..] must disallow [..] only because the sentence starts with Implementation restriction but someone else said may is not necessarily equivalent to must (and I can understand where that version comes from).

As there are 144 mays in the document, I think that some better description of what may or must or may not, in the same style that IETF RFCs always define what must, must not, may and so on represent. This would also help people that are used to RFCs but are not necessarily native English speakers. It would also people that write compilers, static analysis tools and end-users.

Thank you for your consideration.

@dlsniper dlsniper changed the title Clarification for the language specifications doc: Clarification for the language used in the language specifications Feb 29, 2016

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Feb 29, 2016

@ianlancetaylor ianlancetaylor changed the title doc: Clarification for the language used in the language specifications spec: clarification for the language used in the language specifications Feb 29, 2016

@minux

This comment has been minimized.

Copy link
Member

commented Feb 29, 2016

@twotwotwo

This comment has been minimized.

Copy link

commented Feb 29, 2016

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

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Feb 29, 2016

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

@dlsniper

This comment has been minimized.

Copy link
Contributor Author

commented Feb 29, 2016

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.

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Feb 29, 2016

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

@griesemer griesemer modified the milestones: Unreleased, Go1.7 Apr 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.