This change includes several smaller changes based on feedback
received so far.
These changes were reviewed at CL 385536. The only additional
change here is to the current date in the subtitle.
Change-Id: I653eb4a143e3b86c5357a2fd3b19168419c9f432
Reviewed-on: https://go-review.googlesource.com/c/go/+/390634
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The (temporary) highlights will make it easier to review the spec
in formatted form as opposed to html text.
Added a missing rule about the use of adjusted core types for
constraint type inference.
Adjusted rule for invalid embedding of interface types.
Change-Id: Ie573068d2307b66c937e803c486724175415b9c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/385535
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change moves the relevant prose of the section on type parameters
into the section on type parameter lists and eliminates the former.
With this change, the section on types now exclusively describes all
Go composite types.
User-defined named types (defined types and type parameters) are
described with their declarations.
Change-Id: I3e421cd236e8801d31a4a81ff1e5ec9933e3ed20
Reviewed-on: https://go-review.googlesource.com/c/go/+/385037
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also, fixed several closing header tags and removed a duplicate "the".
(Thanks to @hopehook and Hossein Zolfi for pointing these out.)
Change-Id: I85a40ba44b8570a578bce8d211dcc5ea3901fb1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/385036
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The outcome of type inference depends critically on when function
argument type inference stops processing arguments. Describe this
and explain an example with some detail.
Also: In the section on the built-in function delete, refer to the
value rather than the type of the second argument, as it may be an
untyped constant.
Change-Id: Ice7fbb33f985afe082380b8d37eaf763238a3818
Reviewed-on: https://go-review.googlesource.com/c/go/+/385034
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I6de236442f213ab4b4f19ec881add4923d8bfd8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/385054
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Kevin Burke <kevin@burke.dev>
A basic interface is a classical Go interface containing only
methods or embedding basic interfaces.
Use this to simplify rule about what interfaces may be used
where. The term "basic interface" will also be useful when
talking about various interfaces in general.
Fix rule restricting union terms: as it was written it also
excluded interface terms with non-empty method sets due to
embedded non-interface types with methods.
Split the large section on interfaces into three smaller
pieces by introducing section titles.
Change-Id: I142a4d5609eb48aaa0f7800b5b85c1d6c0703fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/384994
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes the prose easier to read while being just as precise.
Change-Id: Ie46c6c5042f419de9fdeb1c75bb72b5a40c37073
Reviewed-on: https://go-review.googlesource.com/c/go/+/384774
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change only shuffles sections for better organization; there
are no other changes except title and link adjustments.
Until now, the sections on underlying types and method sets were
immediately following the introduction of types. As it becomes
necessary to introduce the notion of a core type more centrally,
the natural place is immediately following the section on underlying
types. All together, these sections, immediately after the introduction
of types, would distract from purpose of the section on types, which
is to introduce the various types that Go offers.
The more natural place for the definition of underlying, core, and
specific types is the section on properties of types and values.
To accomplish this, the section on the structure of interfaces is
split into a section on core types and one on specific types, and
the various sections are reorganized appropriately.
The new organization of the section on types now simply introduces
all Go types as follows:
- boolean types
- numeric types
- string types
- array types
- slice types
- struct types
- pointer types
- function types
- interface types
- map types
- channel types
- type parameters
The new organization of the section on properties of types and values
is as follows:
- underlying types
- core types
- specific types
- type identity
- assignability
- representability
- method sets
Change-Id: I59e4d47571da9d4c89d47d777f5353fb1c5843e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/384623
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Includes a few minor cosmetic changes.
Change-Id: I6c307d958b47d83671142688630ea7835168439f
Reviewed-on: https://go-review.googlesource.com/c/go/+/384622
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#51110.
Change-Id: I11370417f1ef435b05dfab18eeabc2c3c1b7b8a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/384674
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add corresponding rules and a couple of examples.
Fixes#50202.
Change-Id: I4287b5e2d0fd29a0c871795e07f1bb529c9c6004
Reviewed-on: https://go-review.googlesource.com/c/go/+/384240
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change in terminology prevents potential confusion
that migth be caused by associating "structural type"
with "structural typing"; the two are not connected.
Also, adjusted introductory paragraph of section on
constraint type inference: type inference goes in both
directions, from type parameter to core type and vice
versa. The previous description was not quite accurate.
Change-Id: If4ca300f525eea660f68486302619aa6ad5dbc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/384238
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The terms "integer type", "floating-point type", and "complex type"
are used frequently in the spec but are not explicitly (only indirectly)
defined.
Slightly rephrased the section on numeric types and introduce these
terms explicitly. Add links to this section.
Change-Id: I3fb888933bece047da8b356b684c855618e9aee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/384157
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Ic338788d6410ed0d09ad129811377ee9ce5ed496
Reviewed-on: https://go-review.googlesource.com/c/go/+/367954
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 380854.
Per the conluding discussions on #50791. A follow-up will
document `comparable` more thoroughly.
For #50791.
Change-Id: I15db9051784a012f713e28d725c3b8bbfeb40569
Reviewed-on: https://go-review.googlesource.com/c/go/+/381076
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Mostly from CL 367954.
Change-Id: Id003b0f785a286a1a649e4d6e8c87d0418a36545
Reviewed-on: https://go-review.googlesource.com/c/go/+/379920
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Introduce a (local) notion of a set of representative types,
which serves as a representation/approximation of an
interface's actual type set. If the set of representative
types is is non-empty and finite, it corresponds to the set
of specific types of the interface.
In the implementation, the set of representative types serves
as a finite representation of an interface's type set, together
with the set of methods.
Change-Id: Ib4c6cd5e17b81197672e4247be9737dd2cb6b56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Problem pointed out on golang-nuts mailing list.
Change-Id: If1c9b22e1ed7b4ec7ebcaadc80fa450333e6856c
Reviewed-on: https://go-review.googlesource.com/c/go/+/375799
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new description matches the implementation (CL 370774).
Also, in the section on type constraints, use "defines" instead of
"determines" because the constraint interface defines the type set
which is precisely the set of acceptable type arguments.
For #49482.
Change-Id: I6f30f49100e8ba8bec0a0f1b450f88cae54312eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/372874
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #49602.
Change-Id: I0d3ff8f087dffb3409918494147fd1dceff7514d
Reviewed-on: https://go-review.googlesource.com/c/go/+/372694
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As written, the conversion P(x), where P and the type
of x are type parameters with identical underlying types
(i.e., identical constraints), is valid. However, unless
the type of x and P are identical (which is covered with
the assignability rule), such a conversion is not valid
in general (consider the case where both type parameters
are different type parameters with constraint "any").
This change adjusts the rules to prohibit type parameters
in this case. The same reasoning applies and the analogue
change is made for pointer types.
The type checker already implements these updated rules.
Change-Id: Id90187900cb2820f6a0a0cf582cf26cdf8addbce
Reviewed-on: https://go-review.googlesource.com/c/go/+/371074
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
In preparation for the forthcoming spec changes for #6977.
While at it, modernize existing File example that dates
back all the way to commit 18c5b488a3.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This reverts commit 4b06d9d727.
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>
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>
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>
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>
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>
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>
