aboutsummaryrefslogtreecommitdiff
path: root/doc/go_spec.html
AgeCommit message (Collapse)Author
2021-08-08doc: add example for conversion from slice expressions to array ptrCuong Manh Le
Fixes #47599 Change-Id: I8f4ccd3b0c2bcdb057ee853163b4421229141333 Reviewed-on: https://go-review.googlesource.com/c/go/+/340351 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-07-26doc: clarify non-nil zero length slice to array pointer conversionCuong Manh Le
There is an example for nil slice already, so adding example for non-nil zero length slice, too, clarifying to the reader that the result is also non-nil and different from nil slice case. Updates #395 Change-Id: I019db1b1a1c0c621161ecaaacab5a4d888764b1a Reviewed-on: https://go-review.googlesource.com/c/go/+/336890 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-25spec: use consistent capitalization for rune literal hex constantsIan Lance Taylor
Fixes #47368 Change-Id: I2f65c0008658532123f04d08e99e5d083f33461a Reviewed-on: https://go-review.googlesource.com/c/go/+/337234 Trust: Ian Lance Taylor <iant@golang.org> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-19spec: correct example comment in Conversions from slice to arrayPiers
Fixes #47280 Change-Id: I78a8d235949b4878c7f075ac4ca37700e7e6c31c GitHub-Last-Rev: 067f96eeb2c918eb4f775c428edc945c75af44d8 GitHub-Pull-Request: golang/go#47282 Reviewed-on: https://go-review.googlesource.com/c/go/+/335470 Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Robert Griesemer <gri@golang.org> Trust: Than McIntosh <thanm@google.com>
2021-07-02spec, unsafe: clarify unsafe.Slice docsIan Lance Taylor
For #19367 Change-Id: If0ff8ddba3b6b48e2e198cf3653e73284c7572a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/332409 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-06-28spec: change unsafe.Slice((*T)(nil), 0) to return []T(nil)Matthew Dempsky
Updates #46742. Change-Id: I044933a657cd1a5cdb29863e49751df5fe9c258a Reviewed-on: https://go-review.googlesource.com/c/go/+/331069 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-22spec: unsafe.Add/Slice are not permitted in statement contextRobert Griesemer
Add unsafe.Add and unsafe.Slice to the list of built-in functions which are not permitted in statement context. The compiler and type checker already enforce this restriction, this just fixes a documentation oversight. For #19367. For #40481. Change-Id: Iabc63a8db048eaf40a5f5b5573fdf00b79d54119 Reviewed-on: https://go-review.googlesource.com/c/go/+/329925 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-06-05spec: improve wording consistency by eliminating "specifier"DQNEO
The word "specifier" is used once only here and technically not defined. Change-Id: Ifc9f0582f4eb3c3011ba60d8008234de511d4be6 Reviewed-on: https://go-review.googlesource.com/c/go/+/323730 Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Ian Lance Taylor <iant@golang.org> Trust: Robert Griesemer <gri@golang.org>
2021-06-05spec: improve wording by choosing an official term "keyword"DQNEO
Replace "reserved word" by "keyword" as the latter is the official term. Change-Id: I9f269759b872026034a9f47e4a761cff2d348ca0 Reviewed-on: https://go-review.googlesource.com/c/go/+/323729 Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Ian Lance Taylor <iant@golang.org> Trust: Robert Griesemer <gri@golang.org>
2021-04-28spec: clarify conditions for switch expression typeRobert Griesemer
1. The existing prose implied that a switch expression type must be comparable because it is tested for equality against all case expressions. But for an empty switch (no case expressions), it was not clear if the switch expression needed to be comparable. Require it to match the behavior of compiler and type checkers. 2. While making this change, remove redundant language explaining what happens with untyped boolean switch expression values: the default type of an untyped boolean value is bool, this is already covered by the first part of the relevant sentence. Fixes #43200. Change-Id: Id8e0f29cfa8722b57cd2b7b58cba85b58c5f842b Reviewed-on: https://go-review.googlesource.com/c/go/+/314411 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org>
2021-04-27doc: change <a/> to </a> in speclixianyang
Change-Id: I21d0ee83c9204d51c587bd944209df2232b460ad GitHub-Last-Rev: 47fab8dc582baaab5f5cd58a1d53f1c24604c769 GitHub-Pull-Request: golang/go#45771 Reviewed-on: https://go-review.googlesource.com/c/go/+/313449 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-22spec: add unsafe.Add and unsafe.SliceMatthew Dempsky
Updates #19367. Updates #40481. Change-Id: I578066ad68d2cd6bea50df1a534cf799e4404a7f Reviewed-on: https://go-review.googlesource.com/c/go/+/312212 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2021-04-20spec: allow conversion from slice to array ptrJosh Bleecher Snyder
Implementation follows in subsequent changes. Updates #395 Change-Id: Ic97ee822805e4c236fdd9d224e776cb2ae62c817 Reviewed-on: https://go-review.googlesource.com/c/go/+/216424 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2021-03-17spec: fix rendering of >=Robert Griesemer
Follow-up on https://golang.org/cl/297249. Change-Id: Ib4df91df530e4e7d7dd8c54d89c834cee55031f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/302370 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
2021-03-16spec: clarify that signed integers>=0 are permitted as shift countsnobishino
In Go1.13 and above, signed integers are permitted as shift counts as long as they are >=0. However, the comments in the "Arithmetic operators" section says shift operators accept "unsigned integer" as of right operands. Replacing this with "integer>=0" resolves the misunderstanding that shift operators permit only unsigned integers. Reference: Go1.13 Release Notes: https://golang.org/doc/go1.13 Change-Id: Icd3c7734d539ab702590e992a618c9251c653c37 GitHub-Last-Rev: 4f263a48d3b19ca06a277c5fef78df55e9a92b10 GitHub-Pull-Request: golang/go#44664 Reviewed-on: https://go-review.googlesource.com/c/go/+/297249 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Robert Griesemer <gri@golang.org>
2021-02-24spec: improve sentence structure for passing a sliceDQNEO
Change-Id: I453d06da2f596eb0b99905aec46a05547d73c62c Reviewed-on: https://go-review.googlesource.com/c/go/+/290872 Trust: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Robert Griesemer <gri@golang.org> Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2021-02-20spec: every type has a method set (minor clarification)Robert Griesemer
The spec states that a type "may" have a method set associated with it. Yet every type has a method set, which may be empty. This is clarified later in the same paragraph. Be clear in the first sentence as well. Per the suggestion from https://github.com/DQNEO. Fixes #44318. Change-Id: I6097b1c7062853e404b7fead56d18a7f9c576fc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/292853 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-02-11spec: More precise wording in section on function calls.DQNEO
A caller is not always in a function. For example, a call can appear in top level declarations. e.g. var x = f() Change-Id: I29c4c3b7663249434fb2b8a6d0003267c77268cf Reviewed-on: https://go-review.googlesource.com/c/go/+/290849 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Robert Griesemer <gri@golang.org>
2021-02-02spec: improve the example in Type assertions sectiontask4233
The example, var v, ok T1 = x.(T), can be interpreted as type T1 interface{} or type T = bool; type T1 = T. Separating the example would help understanding for readers. Change-Id: I179f4564e67f4d503815d29307df2cebb50c82f9 GitHub-Last-Rev: b34fffb6bb07cb2883bc313ef3bc9980b3dd4abe GitHub-Pull-Request: golang/go#44040 Reviewed-on: https://go-review.googlesource.com/c/go/+/288472 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Robert Griesemer <gri@golang.org>
2020-10-30spec: split shift examples into groups for 32- and 64-bit intsRobert Griesemer
In the current (pre-CL) version of the spec, the 2nd last shift example appears to be using the array declared in the last example. On a 32-bit platform, that array would have length 0, which would lead to a panic in the 2nd last example. Also, if this code were inside a function, it wouldn't compile (array declared after use). Use an explicitly declared array for that specific shift example. Also, split out all cases that produce different results for 32- vs 64-bit ints. Fixes #41835. Change-Id: Ie45114224509e4999197226f91f7f6f934449abb Reviewed-on: https://go-review.googlesource.com/c/go/+/260398 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-09-24spec: better variable name for operator exampleRobert Griesemer
Suggested by @yaxinlx. Fixes #41612. Change-Id: I98b9968a95d090ee3c67ff02678e1874e6d98c33 Reviewed-on: https://go-review.googlesource.com/c/go/+/257159 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-01-15spec: add missing space in EBNFyah01
Fixes #36520 Change-Id: I698ab235f82f7c81caa09318c954847cf3833153 GitHub-Last-Rev: 368a1dc7889c2370fba272bcb45d94822b60d7b9 GitHub-Pull-Request: golang/go#36559 Reviewed-on: https://go-review.googlesource.com/c/go/+/214821 Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14doc: fix up some HTML issues in go_spec.htmlRob Pike
The HTML linter 'tidy' reports: go_spec.html:2556: Warning: unescaped & which should be written as &amp; go_spec.html:3293: Warning: unescaped & or unknown entity "&s1" go_spec.html:3293: Warning: unescaped & or unknown entity "&a" go_spec.html:3294: Warning: unescaped & or unknown entity "&s2" go_spec.html:3294: Warning: unescaped & or unknown entity "&a" go_spec.html:2045: Warning: trimming empty <p> go_spec.html:4526: Warning: trimming empty <ul> go_spec.html:4533: Warning: trimming empty <ul> go_spec.html:4539: Warning: trimming empty <ul> This CL fixes all but the <ul> ones, which I think should be fixed but are defended by a comment. Change-Id: I0ca88f5e80755024801877ab1298025ecf8f10c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/214457 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
2020-01-13spec: uniformly format empty interfaces as "interface{}"Robert Griesemer
Fixes #36526. Change-Id: Ic51a287579f139422cc1a7b2fb82d6732114b031 Reviewed-on: https://go-review.googlesource.com/c/go/+/214597 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-12-13spec: reword claim about the grammar being regularAlberto Donizetti
Since the word "regular" has a precise meaning in the context of formal languages, the Introduction sentence claiming that Go's grammar is "compact and regular" may mislead readers. Reword it using Rob's suggestion. Fixes #36037 Change-Id: I00c1a5714bdab8878d9a77b36d67dae67d63da0f Reviewed-on: https://go-review.googlesource.com/c/go/+/211277 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2019-09-04spec: clarify that shift count must be non-negativeRobert Griesemer
Fixes #34056. Change-Id: I2c9b7a20d19f458df5dcc376e29bee6be1f09f7a Reviewed-on: https://go-review.googlesource.com/c/go/+/193277 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-26spec: allow embedding overlapping interfacesRobert Griesemer
Updates #6977. Change-Id: I6eda4be550e7c7ea1e1bac3222850002d90a81a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/190378 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-07-31spec: add an example of a trivially invalid interfaceRobert Griesemer
In preparation for the forthcoming spec changes for #6977. While at it, modernize existing File example that dates back all the way to commit 18c5b488a3b. Change-Id: Id10e4df0513e3de15bd58867222923eefa9473ea Reviewed-on: https://go-review.googlesource.com/c/go/+/187978 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-05-14spec: clarify that slice a expression shares underlying array with operandRobert Griesemer
The spec was not very precise as to what happens with respect to sharing if a sliced operand is (a pointer to) an array. Added a small clarification and a supporting example. Fixes #31689. Change-Id: Ic49351bec2033abd3f5428154ec3e9a7c2c9eaa5 Reviewed-on: https://go-review.googlesource.com/c/go/+/177139 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-05-13spec: clarify the difference between &T{} and new(T)Robert Griesemer
Add a small paragraph and example pointing out the difference for the case where T is a slice or map. This is a common error for Go novices. Fixes #29425. Change-Id: Icdb59f25361e9f6a09b190fbfcc9ae0c7d90077b Reviewed-on: https://go-review.googlesource.com/c/go/+/176338 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-05-13spec: clarify language on package-level variable initializationRobert Griesemer
The very first paragraph on "Package initialization" stated that "variables are initialized in declaration order, but after any variables they might depend on". This phrasing was easily misread as "declaration order is the first sorting criteria" and then contradicted what the subsequent paragraphs spelled out in precise detail. Instead, variable initialization proceeds by repeatedly determining a set of ready to initialize variables, and then selecting from that set the variable declared earliest. That is, declaration order is the second sorting criteria. Also, for the purpose of variable initialization, declarations introducing blank (_) variables are considered like any other variables (their initialization expressions may have side-effects and affect initialization order), even though blank identifiers are not "declared". This CL adds clarifying language regarding these two issues and the supporting example. Both gccgo and go/types implement this behavior. cmd/compile has a long-standing issue (#22326). The spec also did not state in which order multiple variables initialized by a single (multi-value) initialization expression are handled. This CL adds a clarifying paragraph: If any such variable is initialized, all that declaration's variables are initialized at the same time. This behavior matches user expectation: We are not expecting to observe partially initialized sets of variables in declarations such as "var a, b, c = f()". It also matches existing cmd/compile and go/types (but not gccgo) behavior. Finally, cmd/compile, gccgo, and go/types produce different initialization orders in (esoteric) cases where hidden (not detected with existing rules) dependencies exist. Added a sentence and example clarifying how much leeway compilers have in those situations. The goal is to preserve the ability to use static initialization while at the same time maintain the relative initialization order of variables with detected dependencies. Fixes #31292. Updates #22326. Change-Id: I0a369abff8cfce27afc975998db875f5c580caa2 Reviewed-on: https://go-review.googlesource.com/c/go/+/175980 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-03-14spec: clarify wording on passing slice arguments to variadic functionsRobert Griesemer
Per discussion on #30769. Fixes #30769. Change-Id: I620dbac936de1a0b5deec03926dd11d690a918e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/167380 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org>
2019-03-12spec: document new Go2 number literalsRobert Griesemer
This CL documents the new binary and octal integer literals, hexadecimal floats, generalized imaginary literals and digit separators for all number literals in the spec. Added empty lines between abutting paragraphs in some places (a more thorough cleanup can be done in a separate CL). A minor detail: A single 0 was considered an octal zero per the syntax (decimal integer literals always started with a non-zero digit). The new octal literal syntax allows 0o and 0O prefixes and when keeping the respective octal_lit syntax symmetric with all the others (binary_lit, hex_lit), a single 0 is not automatically part of it anymore. Rather than complicating the new octal_lit syntax to include 0 as before, it is simpler (and more natural) to accept a single 0 as part of a decimal_lit. This is purely a notational change. R=Go1.13 Updates #12711. Updates #19308. Updates #28493. Updates #29008. Change-Id: Ib9fdc6e781f6031cceeed37aaed9d05c7141adec Reviewed-on: https://go-review.googlesource.com/c/go/+/161098 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-02-17spec: document signed integer shift countsRobert Griesemer
Updates #19113. Change-Id: I4726f51c5061c33979cdd061f6d4616fa97edb9a Reviewed-on: https://go-review.googlesource.com/c/161201 Reviewed-by: Rob Pike <r@golang.org>
2018-11-16doc/go_spec: tweak wording to avoid 'explicit assignment' misreadingRuss Cox
This text changed in CL 139099 to add "explicit" in front of "conversion". But now "explicit conversion or assignment" reads like it might mean "explicit [conversion or assignment]" when what is meant is "[explicit conversion] or assignment". To make clear that explicit does not apply to assignment, use "assignment or explicit conversion". Change-Id: I8ff7a5b3ecd9f562793502fa6808242f22264f28 Reviewed-on: https://go-review.googlesource.com/c/149340 Reviewed-by: Robert Griesemer <gri@golang.org>
2018-11-13spec: be clearer about definition of string lengthRobert Griesemer
Adjusted spec to explicitly define the string length as the number of bytes of the string; the prose now matches the prose for arrays. Made analogous change for slices. Fixes #28736. Change-Id: I47cab321c87de0a4c482f5466b819b2cc8993fd1 Reviewed-on: https://go-review.googlesource.com/c/149077 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-10-23spec: refer to "run-time panic" rather than "exception" (cleanup)Robert Griesemer
Fixes #28341. Change-Id: If8ae844c9b5e843ce9229c0a555f7006426baed7 Reviewed-on: https://go-review.googlesource.com/c/144260 Reviewed-by: Rob Pike <r@golang.org>
2018-10-17spec: clarify rules for receiver base typesRobert Griesemer
The spec currently provides a syntactic rule for receiver base types, and a strict reading of those rules prohibits the use of type aliases referring to pointer types as receiver types. This strict interpretation breaks an assumed rule for aliases, which is that a type literal can always be replaced by an alias denoting that literal. Furthermore, cmd/compile always accepted this new formulation of the receiver type rules and so this change will simply validate what has been implemented all along. Fixes #27995. Change-Id: I032289c926a4f070d6f7795431d86635fe64d907 Reviewed-on: https://go-review.googlesource.com/c/142757 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-10-08spec: distinguish between explicit and implicit conversions (clarification)Robert Griesemer
The spec used the term "conversion" somewhat indiscriminately for explicit conversions that appear literally in the source, and implicit conversions that are implied by the context of an expression. Be clearer about it by defining the terms. Also, state that integer to string conversions of the form string(x) are never implicit. This clarifies situations where implicit conversions might require an integer to change to a string (but don't and never have done so). See line 3948. Fixes #26313. Change-Id: I8939466df6b5950933ae7c987662ef9f88827fda Reviewed-on: https://go-review.googlesource.com/c/139099 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-09-24spec: be more precise about the moment deferred functions are executedRobert Griesemer
Fixes #27802. Change-Id: I7ea9f7279300a55b0cb851893edc591a6f84e324 Reviewed-on: https://go-review.googlesource.com/136758 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-08-31doc: fix os.Pipe() call in the example.Dina Garmash
Short variable declarations example passes an fd argument to os.Pipe call. However, os.Pipe() takes no arguments and returns 2 Files and an error: https://golang.org/src/os/pipe_linux.go?s=319:360#L1 Fixes: #27384 Change-Id: I0a709f51e0878c57185d901b899d209f001dfcce Reviewed-on: https://go-review.googlesource.com/132284 Reviewed-by: Robert Griesemer <gri@golang.org>
2018-06-13doc: use HTTPS for linksSuriyaa Sundararuban
Change-Id: I9d2d25df067ca573589db5ff18296a5ec33866be Reviewed-on: https://go-review.googlesource.com/118595 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-05-09spec: clarify “Constant expressions” for untyped operandsBryan C. Mills
This change addresses the grammatical complexity described in https://groups.google.com/forum/#!topic/golang-dev/RmP-LMC3g58. Change-Id: Ib292b4ca9c880c7c1c8c992e7c033a0f8f951f2c Reviewed-on: https://go-review.googlesource.com/106855 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2018-03-19Revert "doc: remove non-prime from list of primes in spec"Andrew Bonventre
This reverts commit 4b06d9d72747b0407e2cd9a423b689c7e9c8e92d. Reason for revert: It's a reference to a legendary article from the Journal of Irreproducible Results. Updates golang/go#24451 Change-Id: I0288177f4e286bd6ace5774f2e5e0acb02370305 Reviewed-on: https://go-review.googlesource.com/101495 Reviewed-by: Andrew Bonventre <andybons@golang.org>
2018-03-19doc: remove non-prime from list of primes in specAndrew Bonventre
Fixes golang/go#24451 Change-Id: Id9b4cbd1a1ff032f1cc4606e9734ddcc64892ae5 Reviewed-on: https://go-review.googlesource.com/101457 Reviewed-by: Filippo Valsorda <filippo@golang.org>
2018-02-19doc: improve clarity of map index examplesYazen2017
The fourth example for map indexing states you have a map of type [K]V and attempts to read in a variable of type T. Further, the example is meant to showcase the boolean return variable saying whether the map contained a key, but overrides to type T. This will not compile. Changed last updated date to February 18 Fixes: #23895 Change-Id: I63c52adbcd989afd4855e329e6c727f4c01f7881 Reviewed-on: https://go-review.googlesource.com/94906 Reviewed-by: Robert Griesemer <gri@golang.org>
2018-02-02spec: remove need for separate Function production (cleanup)Robert Griesemer
The EBNF production Function = Signature FunctionBody . was used in FunctionDecl, MethodDecl, and FunctionLit, but only for the latter it shortened the syntax slightly. This change "inlines" Function which simplifies FunctionDecl and MethodDecl and gets rid of the Function production. This has no impact on the specified language. Also, the Function production is never referred to by the prose, so it's safe to remove it from the spec. Finally, neither go/ast nor go/parser have a representation of this production via a corresponding node or parse function, so no possibly valuable documentation is lost, either. Change-Id: Ia2875d31c6ec2d2079081ef481e50bad4f43c694 Reviewed-on: https://go-review.googlesource.com/91515 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2018-01-23spec: consistently use "defined type" and "type name" (cleanup)Robert Griesemer
When we introduced the notion of alias type declarations, we renamed "named type" to "defined type" to avoid confusion with types denoted by aliases and thus are also types with names, or "named types". Some of the old uses of "named types" remained; this change removes them. Now the spec consistently uses the terms: - "defined type" for a type declared via a type definition - "type name" for any name denoting an (alias or defined) type - "alias" for a type name declared in an alias declaration New prose is encouraged to avoid the term "named type" to counter- act further confusion. Fixes #23474. Change-Id: I5fb59f1208baf958da79cf51ed3eb1411cd18e03 Reviewed-on: https://go-review.googlesource.com/89115 Reviewed-by: Rob Pike <r@golang.org>
2018-01-17spec: mention that special case for integer division is due to overflowRobert Griesemer
Fixes #23443. Change-Id: If60c39b582ee5308e9fa902f93c1b6ae7890346c Reviewed-on: https://go-review.googlesource.com/87975 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2018-01-11spec: remove example explaining that type B0 and B0 are identicalRobert Griesemer
Every few months we get a new error report claiming that there is a typo in the spec related to this specific example. Clearly, the fact that two types with the same identifier are identical seems exceedingly obvious to readers; thus the example seems not worth the trouble. Removing it. For #9226. For #22202. For #22495. For #23096. For #23409. There may be more. Change-Id: I003ba79dc460ffb028a4ecb5f29efd60f2551912 Reviewed-on: https://go-review.googlesource.com/87417 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion