This CL is partly based on CL 510535.
For #61405.
Change-Id: Ic94f6726f9eb34313f11bec7b651921d7e5c18d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/538859
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Fixes#63525.
Change-Id: Ie9aa4dd47c025cd593e576c6e8de1774e1d1e302
Reviewed-on: https://go-review.googlesource.com/c/go/+/535775
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This CL clarifies the order of evaluation of the binary logical
operators, && and ||. The clarified semantics matches what cmd/compile
and x/tools/go/ssa already implement, and prohibit some optimizations
that are arguably allowed today but risk surprising users.
First, it specifies that the left operand is evaluated before the
right operand. This prohibits "(f() || true) && *p" from evaluating
"*p" before "f()".
Second, it specifies that binary logical operations are also ordered
lexically left-to-right with regard to function calls and receive
operations. This prohibits "h(*p || true || f(), g())" from evaluating
"*p" after "g()".
Finally, the "order of evaluation of [...] is not specified" wording
in the example is clarified to acknowledge that there are still some
other orderings that are implied lexically; e.g., x must be evaluated
and indexed before g(), and z now must be evaluated before h(). (Note:
Whether z is evaluated before or after f() remains unspecified, as
there's no lexical dependency.)
Change-Id: I9d316a7f1fbc83be663e116380a2cc7a4ace623d
Reviewed-on: https://go-review.googlesource.com/c/go/+/522938
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The example text below suggests that []byte("") always evaluates to
the non-nil value []byte{}, but the text proper doesn't explicitly
require that. This CL makes it clear that it must not evaluate to
[]byte(nil), which otherwise was allowed by the wording.
Change-Id: I6564bfd5e2fd0c820d9b55d17406221ff93ce80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/521035
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Change-Id: I40595a3f598483d029473af465c756f8777ecc91
Reviewed-on: https://go-review.googlesource.com/c/go/+/520915
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Irrespective of whether unification is exact or inexact, method
signatures of interfaces must always match exactly: a type never
satisfies/implements an interface if relevant method signatures
are different (i.e., not identical, possibly after substitution).
This change matches the fix https://go.dev/cl/519435.
For #61879.
Change-Id: I28b0a32d32626d85afd32e107efce141235a923d
Reviewed-on: https://go-review.googlesource.com/c/go/+/519455
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Change-Id: I06345199ff16c80be83c345d734caef1714ec089
Reviewed-on: https://go-review.googlesource.com/c/go/+/515338
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Change-Id: I0d4ccbc396c48d565c0cbe93c9558ab330a44d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/513275
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
This leaves the specific unification details out in favor
of a (forthcoming) section in an appendix.
Change-Id: If984c48bdf71c278e1a2759f9a18c51ef58df999
Reviewed-on: https://go-review.googlesource.com/c/go/+/507417
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Change-Id: I9cdb301163b67add39928c8fc7df2b7f3893f45e
Reviewed-on: https://go-review.googlesource.com/c/go/+/511836
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The new section describes type inference as the problem
of solving a set of type equations for bound type parameters.
The next CL will update the section on unification to match
the new inference approach.
Change-Id: I2cb49bfb588ccc82d645343034096a82b7d602e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/503920
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Per feedback on #56351.
For #56351.
Change-Id: I63dd1713a1efe4d7180d932dbd8e1510cbb32e90
Reviewed-on: https://go-review.googlesource.com/c/go/+/510935
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Change-Id: I9f008dba7ba6e30f0e62647482a3ed0b51bc1ad0
Reviewed-on: https://go-review.googlesource.com/c/go/+/502997
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Fixes#60731.
Change-Id: I71fad1c8385b13d036bb0ce7ae6bd21e0f596e51
Reviewed-on: https://go-review.googlesource.com/c/go/+/502657
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
For #57411.
Change-Id: I94982d939d16ad17174f801cc167cc10ddc8da30
Reviewed-on: https://go-review.googlesource.com/c/go/+/501696
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The section on type inference has not been updated yet for Go 1.21.
Add a temporary note so that readers referred to this section from
the release notes are not confused.
Change-Id: Idc4c74d6d700f891c625289e873ad5aa9c2c5213
Reviewed-on: https://go-review.googlesource.com/c/go/+/501308
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Fixes#60570.
Change-Id: I7ef834731ea26ceee5ec9b7438fdd8323aaf828e
Reviewed-on: https://go-review.googlesource.com/c/go/+/500416
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #59488.
Change-Id: I50f65216bf02b42c1e0619702833f4a6dbed8925
Reviewed-on: https://go-review.googlesource.com/c/go/+/498136
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Put the sections for the various built-ins into alphabetical order
based on the built-in name, while keeping built-ins that belong
together together.
The order is now (captialized letter determines order):
- Append
- Clear
- Close
- Complex, real, imag
- Delete
- Len, cap
- Make
- Min, max (to be inserted here)
- New
- Panic, recover
- Print, println
There are some white space adjustments but no changes to the prose
of the moved sections.
Change-Id: Iaec509918c6bc965df3f28656374de03279bdc9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/498135
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
"placeholder" (no space) is already used in the spec and seems to be
the preferred option.
Removed space from "place holder".
Change-Id: I9b98f62f0e3f5adb019b99f5271cc9d19abf505e
GitHub-Last-Rev: ed5aaf9d02
GitHub-Pull-Request: golang/go#59626
Reviewed-on: https://go-review.googlesource.com/c/go/+/484576
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
In the language specification under "Constants" the lists matching default
types to untyped contstant types is missing an Oxford comma in the first
list. I found a number of other places in the spec and #23442 that use the
Oxford comma to support its use.
Add missing Oxford comma in Constants default type list.
Change-Id: I4562d692610334bc82452db076145d2414617a04
GitHub-Last-Rev: 8acdb60d6e
GitHub-Pull-Request: golang/go#59528
Reviewed-on: https://go-review.googlesource.com/c/go/+/483555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Fixes#59506
Change-Id: I2f8b92e93b706b061ca0eb0bd52e5cf798ce9ede
Reviewed-on: https://go-review.googlesource.com/c/go/+/483358
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The typechecker already enforces this semantic, but the spec is not
updated when unsafe.{SliceData,String,StringData} were added.
Change-Id: I4ee8c564d5681b2a5fd31ff424a31bdf065d9f3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/467756
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I5e3aca2b8fc78f38c9e2cdc67adf86d57ac85b1c
GitHub-Last-Rev: 0e5ddffe33
GitHub-Pull-Request: golang/go#58353
Reviewed-on: https://go-review.googlesource.com/c/go/+/465615
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Long ago we decided that panic(nil) was too unlikely to bother
making a special case for purposes of recover. Unfortunately,
it has turned out not to be a special case. There are many examples
of code in the Go ecosystem where an author has written panic(nil)
because they want to panic and don't care about the panic value.
Using panic(nil) in this case has the unfortunate behavior of
making recover behave as though the goroutine isn't panicking.
As a result, code like:
func f() {
defer func() {
if err := recover(); err != nil {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
}
looks like it guarantees that call2 has been run any time f returns,
but that turns out not to be strictly true. If call1 does panic(nil),
then f returns "successfully", having recovered the panic, but
without calling call2.
Instead you have to write something like:
func f() {
done := false
defer func() {
if err := recover(); !done {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
done = true
}
which defeats nearly the whole point of recover. No one does this,
with the result that almost all uses of recover are subtly broken.
One specific broken use along these lines is in net/http, which
recovers from panics in handlers and sends back an HTTP error.
Users discovered in the early days of Go that panic(nil) was a
convenient way to jump out of a handler up to the serving loop
without sending back an HTTP error. This was a bug, not a feature.
Go 1.8 added panic(http.ErrAbortHandler) as a better way to access the feature.
Any lingering code that uses panic(nil) to abort an HTTP handler
without a failure message should be changed to use http.ErrAbortHandler.
Programs that need the old, unintended behavior from net/http
or other packages can set GODEBUG=panicnil=1 to stop the run-time error.
Uses of recover that want to detect panic(nil) in new programs
can check for recover returning a value of type *runtime.PanicNilError.
Because the new GODEBUG is used inside the runtime, we can't
import internal/godebug, so there is some new machinery to
cross-connect those in this CL, to allow a mutable GODEBUG setting.
That won't be necessary if we add any other mutable GODEBUG settings
in the future. The CL also corrects the handling of defaulted GODEBUG
values in the runtime, for #56986.
Fixes#25448.
Change-Id: I2b39c7e83e4f7aa308777dabf2edae54773e03f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/461956
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Fixes#40882.
Change-Id: I90f99d75e6d66f857b6ab8789c6d436f85d20993
Reviewed-on: https://go-review.googlesource.com/c/go/+/457515
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
For #56548.
Fixes#57012.
Change-Id: I44f850522e52b1811025fb31bcef289da8f8089d
Reviewed-on: https://go-review.googlesource.com/c/go/+/457437
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
- Rephrase the notion of "comparability" from a property
of values (operands) to a property of types and adjust
dependent prose.
- Introduce the notion of "strict comparability".
- Fix the definitions of comparability for type interfaces
and type parameters.
- Define the predeclared identifier "comparable" as stricly
comparable.
These changes address existing problems in the spec as outlined
in the section on "Related spec issues" in issue #56548.
For #56548.
Change-Id: Ibc8c2f36d92857a5134eadc18358624803d3dd21
Reviewed-on: https://go-review.googlesource.com/c/go/+/457095
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Document that a slice can be converted to either an array or a pointer
to an array of a matching underlying array type. This was documented in
the "Conversions from slice to array or array pointer" subsection, but
not in the list of conversion rules.
Updates #46505.
Change-Id: I16a89a63ef23c33580129952415e977a8f334009
Reviewed-on: https://go-review.googlesource.com/c/go/+/452936
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Tim King <taking@google.com>
If needed, the built-in function append allocates a new underlying
array. While we (probably) don't want to specify exactly how much
is allocated (the prose is deliberately vague), if there's more
space allocated than needed (cap > len after allocation), that
extra space is zeroed. Use an explicit link to the section on
Allocation which explicitly states that newly allocated memory
is zeroed.
Fixes#56684.
Change-Id: I9805d37c263b87860ea703ad143f738a0846247e
Reviewed-on: https://go-review.googlesource.com/c/go/+/452619
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
At parse time we don't know if a[i] is an index expression or a
type (or function) instantiation. Because instantiations accept
a list of type arguments, and argument lists permit a trailing
comma, a[i,] is either an instantiation or index expression.
Document that a trailing comma is permitted in the syntax for
index expressions.
For comparison, the same problem arises with conversions which
cannot be distinguished from function calls at parse time. The
spec also permits a trailing comma for conversions T(x,). The
grammar adjustment is the same (see line 5239).
Fixes#55007.
Change-Id: Ib9101efe52031589eb95a428cc6dff940d939f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/452618
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #53003.
Change-Id: If5d76c7b8dfcbcab919cad9c333c0225fc155859
Reviewed-on: https://go-review.googlesource.com/c/go/+/449537
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Fixes#8606.
Change-Id: I64b13b2ed61ecae4641264deb47c9f7653a80356
Reviewed-on: https://go-review.googlesource.com/c/go/+/449536
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Converting from nil slice to zero element array is ok, so explicitly
describe the behavior in the spec.
For #46505
Change-Id: I68f432deb6c21a7549bf7e870185fc62504b37f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/430835
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For #46505.
Change-Id: I1a30fd895496befd16626afb48717ac837ed5778
Reviewed-on: https://go-review.googlesource.com/c/go/+/429315
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
This permits a clear distinction between an individual assignment
and an assignment statement which may assign more than one value.
It also makes this section title consistent with all other section
titles about statements. Adjust internal links and prose where
appropriate. (Note that the spec already referred to assignment
statements in a couple of places, even before this change.)
Add an introductory paragraph to the section on assignment statements.
Preparation for adding a section on value vs reference types
(issue #5083).
Change-Id: Ie140ac296e653c67da2a5a203b63352b3dc4f9f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/413615
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Pre-1.18, as special cases, the built-in operations append and copy
accepted strings as second arguments if the first argument was a byte
slice. With Go 1.18, these two built-ins as well as slice expressions
rely on the notion of core types in their specification.
Because we want to permit slice expressions, append, and copy to
operate on (1st or 2nd operands) that are type parameters restricted
by []byte | string (and variations thereof), the simple notion of
core type is not sufficient for these three operations. (The compiler
already permits such more relaxed operations).
In the section on core types, add a paragraph and examples introducing
the (artificial) core type "bypestring", which describes the core type
of type sets whose underlying types are []byte or string. Adjust the
rules for slice expressions, append, and copy accordingly.
Also (unrelated): Adjust prose in the only paragraph where we used
personal speech ("we") to impersonal speech, to match the rest of
the spec.
Fixes#52859.
Change-Id: I1cbda3095a1136fb99334cc3a62a9a349a27ce1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/412234
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Add an additional example.
Fixes#53217.
Change-Id: I899376b9c1fa8dc5d475d8d3d6c8788ab79b0847
Reviewed-on: https://go-review.googlesource.com/c/go/+/412238
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The spec section on conversions uses the terms "slice of bytes" and
"slice of runes". While not obviously clear, what is meant are slice
types whose element types are byte or rune types; specifically the
underlying types of the slices' element types must be byte or rune.
Some of this was evident from the examples, but not all of it. Made
this clearer by adding more examples illustrating various permitted
conversions.
Note that the 1.17 compiler did not accept the following conversions:
string([]myByte{...})
string([]myRune{...})
myString([]myByte{...})
myString([]myRune{...})
(where myByte, myRune, and myString have underlying types of byte,
rune, and string respectively) - it reported an internal error.
But it did accept the inverse conversions:
[]myByte("...")
[]myRune("...")
[]myByte(myString("..."))
[]myRune(myString("..."))
The 1.18 compiler made those conversions symmetric and they are now
permitted in both directions.
The extra examples reflect this reality.
Fixes#23814.
Change-Id: I5a1c200b45ddd0e8c0dc0d11da3a6c39cb2dc848
Reviewed-on: https://go-review.googlesource.com/c/go/+/412094
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The spec already states that the precise behavior of the map size
hint provided to the make built-in is implementation-dependent.
Exclude requiring specific run-time behavior for maps.
(The current Go compiler does not panic if the size hint is negative
at run-time.)
Fixes#53219.
Change-Id: I2f3618bf9ba4ed921e18dc4f2273eaa770805bd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/411919
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Types may be generic, so each occurrence of a TypeName may be
followed by optional type arguments. Add the missing syntactic
(EBNF) factor.
The syntax of type names followed by type arguments matches the
syntax of operand names followed by type arguments (operands may
also be types, or generic functions, among other things). This
opens the door to factoring out this shared syntax, but it will
also require some adjustments to prose to make it work well.
Leaving for another change.
Fixes#53240.
Change-Id: I15212225c28b27f7621e3ca80dfbd131f6b7eada
Reviewed-on: https://go-review.googlesource.com/c/go/+/411918
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
