Change-Id: I562d4648756e710020ee491f3801896563a89baa
Reviewed-on: https://go-review.googlesource.com/c/go/+/367395
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We want to support some special cases for index expressions, len, and
cap on operands of type parameters (such as indexing a value constrained
by byte slices and strings), hence the extra rules.
Change-Id: I4a07dc7e64bb47361b021d606c52eae1784d5430
Reviewed-on: https://go-review.googlesource.com/c/go/+/366814
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
- fix definition of "specific types" and add more examples
- state that a parameterized function must be instantiated
when used as a function value
- remove duplicate word ("can can" -> "can")
Thanks to @danscales for finding these.
Change-Id: Ideb41efc35a3e67694d3bc97e462454feae37c44
Reviewed-on: https://go-review.googlesource.com/c/go/+/367394
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This change corrects the link `Instantiantions` to `Instantiations` in the spec.
Change-Id: Ib0ed03420ae401d20af1ea723c5487018b2f462d
GitHub-Last-Rev: b84316c818
GitHub-Pull-Request: golang/go#49816
Reviewed-on: https://go-review.googlesource.com/c/go/+/367274
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Change-Id: I11111b3617673be94508128489aed6488d518537
Reviewed-on: https://go-review.googlesource.com/c/go/+/366834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I5ffc7f26236487070447eaa0f6b14d1fab44c3c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/366794
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I2770da87b4c977b51dfa046f2f08283917675e1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/365916
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Change-Id: I7bfddf4be0d1d95419f312bb349ae2e16b74b795
Reviewed-on: https://go-review.googlesource.com/c/go/+/365915
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I3c4d8bdb5e92ee7fdca9593fb043f94f467755e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/365434
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I4423a059527066c4418c195911f8184dfd3f5a15
Reviewed-on: https://go-review.googlesource.com/c/go/+/365914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The notion of specific types will be used to define rules for
assignability, convertability, etc. when type parameters are
involved.
Change-Id: Ic5c134261e2a9fe05cdf25efd342f052458ab5c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/366754
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Thanks to @danscales for noticing the mistake.
Change-Id: I547ee80a78419765b82d39d7b34dc8d3bf962c35
Reviewed-on: https://go-review.googlesource.com/c/go/+/366215
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This change introduces the notion of a structural interface
and its corresponding structural type.
Change-Id: Ib5442dfd04cb5950b4467428cae51849f8922272
Reviewed-on: https://go-review.googlesource.com/c/go/+/365474
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- add section on type parameters
- added two sections on the scope of type parameters
- expanded general section on types accordingly
- introduced the notion of a named type which will
help in simplifying various rules (subsequent CLs)
Change-Id: I49c1ed7d6d4f951d751f0a3ca5dfb637e49829f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/365414
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I29e9188a0fa1326c2755a9b86aeb47feaa8019be
Reviewed-on: https://go-review.googlesource.com/c/go/+/365274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- fixed a typo in the method set section
- express in the syntax that ~T denotes an underlying type
- be more precise when talking about types vs type terms
- refer to "unions" rather than "union expressions"
- make it clear in the spec title that this is WIP
Change-Id: I9b2c4b1f77bc50dd574ed6893bedd40529c320fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/365154
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is the first of several CLs that update the existing
Go 1.17 spec for type parameters.
This CL updates the section on method sets and interface types.
It also adds "any", "comparable" to the list of predeclared
identifiers.
Change-Id: I0ce25dc02791c33150c0d949528512610faf3eab
Reviewed-on: https://go-review.googlesource.com/c/go/+/362999
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Thanks for jtagcat@ for finding this.
Change-Id: If7324808edbae19ec8bf503b04e0426f3fb3b47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363394
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Thanks to @bodar (Github) for finding this.
Fixes#48422.
Change-Id: I031c3d82a02db1d204e2b86b494d89784d37f073
Reviewed-on: https://go-review.googlesource.com/c/go/+/350409
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 85215 added prose to provide some minimal intuition for the
definition of a "terminating statement". While the original definition
was perfectly fine, the added prose was actually incorrect: If the
terminating statement is a goto, it might jump to a labeled statement
following that goto in the same block (it could be the very next
statement), and thus a terminating statement does not in fact
"prevent execution of all statements that lexically appear after
it in the same block".
Rather than explaining the special case for gotos with targets that
are lexically following the goto in the same block, this CL opts for
a simpler approach.
Thanks to @3bodar (Github) for finding this.
Fixes#48323.
Change-Id: I8031346250341d038938a1ce6a75d3e687d32c37
Reviewed-on: https://go-review.googlesource.com/c/go/+/349172
Trust: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
So it's clear to the reader that if "M" is a promoted method from
embedded field "T", then "x.M" will be expanded to "x.T.M" during the
evaluation of the method value.
Fixes#47863
Change-Id: Id3b82127a2054584b6842c487f6e15c3102dc9fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/344209
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: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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>
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>
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>
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>
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>
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>
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: 4f263a48d3
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>
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>
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>
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>
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: b34fffb6bb
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>
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>
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>
The HTML linter 'tidy' reports:
go_spec.html:2556: Warning: unescaped & which should be written as &
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>
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>
