The spec explains later in the "Operator precedence" section that *
has a higher precedence than +, but the current production rule
requires that "1 + 2 * 3" be parsed as "(1 + 2) * 3", instead of the
intended "1 + (2 * 3)".
The new production rule better matches cmd/internal/gc/go.y's grammar:
expr:
uexpr
| expr LOROR expr
| expr LANDAND expr
| ...
Fixes#10151.
Change-Id: I13c9635d6ddf1263cafe7cc63e68f3e5779e24ba
Reviewed-on: https://go-review.googlesource.com/9163
Reviewed-by: Robert Griesemer <gri@golang.org>
to map element keys
Composite literals containing element values that are themselves composite
literals may leave away the element's literal types if they are identical
to the enclosing composite literal's element type.
(http://golang.org/ref/spec#Composite_literals)
When we made this change, we forgot to apply the analogous rule to map
literal keys. This change generalizes that rule. Added more examples,
including one showing the recursive application of the elision rules.
This is a fully backward-compatible language change. It was discussed
some time back.
Fixes#8589.
To be submitted once all compilers accept the extension.
Change-Id: I4d45b64b5970f0d5501572945d5a097e64a9458b
Reviewed-on: https://go-review.googlesource.com/2591
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Language clarification.
The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).
However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.
Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).
Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.
Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:
See http://play.golang.org/p/c6VhjcIVdM , line 45.
Fixes#5769.
Fixes#8989.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043
Not a language change.
This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both
len(s)
and
(((len)))(s)
are accepted by all compilers and go/types.
Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).
The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.
Fixes#9001.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, dave
CC=golang-codereviews
https://golang.org/cl/160570043
Per suggestion from rsc as a result of the dicussion of
(abandoned) CL 153110044.
Fixes#7192.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/163050043
Not a language change.
Several inaccuracies were fixed:
1) A variable declaration may declare more than just one
variable.
2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.
3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).
4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.
To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.
Fixes#8088.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for
var (
c = b + 2
a = 0
b = 1
)
because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.
The new rules are given in form of an algorithm which outlines
initialization order explicitly.
gccgo and go/types already follow these rules.
Fixes#8485.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
The proposed text in the last CL had a comma that was missing from the submitted spec.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043
Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).
No content changes besides the section moves.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/132300043
Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.
The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).
Fixes#8189.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
This is a fully backward-compatible language change.
There are not a lot of cases in the std library, but
there are some. Arguably this makes the syntax a bit
more regular - any trailing index variable that is _
can be left away, and there's some analogy to type
switches where the temporary can be left away.
Implementation-wise the change should be trivial as
it can be done completely syntactically. For instance,
the respective change in go/parser is a dozen lines
(see https://golang.org/cl/112970044 ).
Fixes#6102.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/104680043
This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.
This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:
a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma
The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.
Noteworthy:
- gc already permits a trailing comma at the end of a receiver
declaration:
func (recv T,) m() {}
This is technically a bug with the current spec; this CL will
legalize this notation.
- gccgo produces a misleading error when a trailing comma is used:
error: method has multiple receivers
(even though there's only one receiver)
- Compilers and type-checkers won't need to report errors anymore
if receiver types are parenthesized.
Fixes#4496.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/101500044
Also made it extra clear for goto statements (even though label scopes
are already limited to the function defining a label).
Fixes#8040.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/99550043
The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.
Discussion:
Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.
It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.
There appear to be two "reasonable" alternatives:
1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.
2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.
Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.
Fixes#6604.
LGTM=r, rsc, iant
R=r, rsc, ken, iant
CC=golang-codereviews
https://golang.org/cl/99410046
The spec did not specify the order in which
init() functions are called. Specify that
they are called in source order since we have
now also specified the initialization order
of independent variables.
While technically a language change, no
existing code could have relied on this,
so this should not break anything.
Per suggestion from rsc.
LGTM=r, iant
R=rsc, iant, r, ken
CC=golang-codereviews
https://golang.org/cl/98420046
- split description of package initialization and
program execution
- better grouping of concerns in section on package
initialization
- more explicit definition of what constitues a
dependency
- removed language about constant dependencies -
they are computed at compile-time and not
initialized at run-time
- clarified that independent variables are initialized
in declaration order (rather than reference order)
Note that the last clarification is what distinguishes
gc and gccgo at the moment: gc uses reference order
(i.e., order in which variables are referenced in
initialization expressions), while gccgo uses declaration
order for independent variables.
Not a language change. But adopting this CL will
clarify what constitutes a dependency.
Fixes#6703.
LGTM=adonovan, r, iant, rsc
R=r, rsc, iant, ken, adonovan
CC=golang-codereviews
https://golang.org/cl/99020043
- use previously defined terms (with links) throughout
- specify evaluation order more precisely (in particular,
the evaluation time of rhs expressions in receive cases
was not specified)
- added extra example case
Not a language change.
Description matches observed behavior of code compiled
with gc and gccgo.
Fixes#7669.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, josharian
CC=golang-codereviews
https://golang.org/cl/91230043
- A channel may be used between any number of goroutines,
not just two.
- Replace "passing a value" (which is not further defined)
by "sending and receiving a value".
- Made syntax production more symmetric.
- Talk about unbuffered channels before buffered channels.
- Clarify what the comma,ok receive values mean (issue 7785).
Not a language change.
Fixes#7785.
LGTM=rsc, r, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/94030045
This is a clarification of what happens already.
Not a language change.
Fixes#7137.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/96000044
If the underlying type of a type T is a boolean, numeric,
or string type, then T is also a boolean, numeric, or
string type, respectively.
Not a language change.
Fixes#7551.
LGTM=iant, rsc, robert.hencke, r
R=r, rsc, iant, ken, robert.hencke
CC=golang-codereviews
https://golang.org/cl/100130044
Currently tip.golang.org leads to golang.org and
local godoc also leads to golang.org (when you don't have internet connectivity).
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/100200043
This documents the status quo for most implementations,
with one exception: gc generates a run-time error for
constant but out-of-range indices when slicing a constant
string. See issue 7200 for a detailed discussion.
LGTM=r
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/72160044
The underlying type of the predeclared type error is not itself,
but the interface it is defined as.
Fixes#7444.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/71790044
This documents the implemented behavior of both
gc and gccgo as an implementation restriction.
NOT A LANGUAGE CHANGE.
Fixes#5425.
LGTM=rsc, r, iant
R=r, iant, rsc, ken
CC=golang-codereviews
https://golang.org/cl/71430043
gccgo considers built-in function calls returning a constant not as function call (issue 7386)
go/types considers any call (regular or built-in) as a function call
The wording and examples clarify that only "function calls" that are issued
at run-time (and thus do not result in a constant result) are considered
function calls in this case.
gc is inconsistent (issue 7385)
gccgo already interprets the spec accordingly and issue 7386 is moot.
go/types considers all calls (constant or not) as function calls (issue 7457).
Fixes#7387.
Fixes#7386.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/66860046
An absent condition/tag in for and switch statements is equivalent
to the predeclared constant true; not simply the expression true
(which might lead to a locally defined true).
Not a language change.
Fixes#7404.
LGTM=iant, r
R=r, iant, rsc, ken
CC=golang-codereviews
https://golang.org/cl/68150046
No change to the meaning, just bad writing found by
Doug McIlroy.
Let's start the new year off with a bang.
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/47110044
Please note the slight rewording for append: The spec now
requires that append reuses the underlying array if it is
sufficiently large. Per majority sentiment.
This is technically a language change but the current
implementation always worked this way.
Fixes#5818.
Fixes#5180.
R=rsc, iant, r, ken, minux.ma, dan.kortschak, rogpeppe, go.peter.90
CC=golang-dev
https://golang.org/cl/14419054
Make the break example slightly more interesting
Update #5725
Effective Go will be updated in a separate CL.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13368054
Remove "References" section.
Remove most articles and redirect to blog.golang.org.
Move /ref/spec and /ref/mem to /doc/spec and /doc/mem.
Remove duplicate links from the remaining
"Documents", "The Project", and "Help" pages.
Defer to the wiki for more links and community content.
Update command reference and mention cover tool.
Add "Pop-out" text to the front page.
Pick one of four videos at random to feature on the front page.
Fixes#2547.
Fixes#5561.
Fixes#6321.
R=r, dominik.honnef
CC=golang-dev
https://golang.org/cl/13724043
(Replacement for CL 11884043.)
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/12198043
CL submitted prematurely by mistake.
««« original CL description
spec: clarify index and selector expressions
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
»»»
R=r
CC=golang-dev
https://golang.org/cl/12170046
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
The notion of a named type is crucial for the definition
of type identity, assignability, definitions of methods.
Explicitly introduce the notion with an extra sentence.
Fixes#5682.
R=r, rsc, iant
CC=golang-dev
https://golang.org/cl/11055043
The existing compilers convert empty strings to empty
but non-nil byte and rune slices. The spec required
a nil byte and rune slice in those cases. That seems
an odd additional requirement. Adjust the spec to
match the reality.
Also, removed over-specification for conversions of
nil []byte and []rune: such nil slices already act
like empty slices and thus don't need extra language.
Added extra examples instead.
Fixes#5704.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/10440045
Several old TODOs are either resolved now (e.g. when is a return
needed), or are from a time the language wasn't frozen (^ for uints
only). Consolidated the others.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9599044
Although one may argue that they should be legal, gc (at least)
disallows byte order marks that are not the first code point
in the file. Added a sentence to the "Implementation restriction"
clause in the "Source code representation" section to document
this better.
Lifting this restriction (again - the rule has changed at least
twice already) would not break any existing programs, should
we later decide yet again to fiddle the rules about these little
fly specks.
R=golang-dev, dsymonds, gri
CC=golang-dev
https://golang.org/cl/8649043
Also:
- more consistenly use "xxx" statement rather than <code>xxx</code> statement
- fix/remove unnecessary links
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7821050
Will help people find the rules by searching the spec by
having a comment saying "missing return";
"terminating statement" does not evoke the rule to the
uninitiated.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7838044
The rule is not concistently followed by gc.
It appears that gccgo is ignoring it. go/types
does not implement this rule. However, both
gccgo and now go/types can compile/type-check
the entire std library (and thus all the shift
expressions occuring in it) w/o errors. For
more details see the discussion in issue 4883.
Fixes#4880.
Fixes#4881.
Fixes#4883.
R=rsc, r, iant, ken, ken, mtj, rogpeppe
CC=golang-dev
https://golang.org/cl/7707043
The only functional change is the new section
on terminating statements.
There is a minor syntax rewrite (not change)
of function declarations to make it easier to
refer to the notion of a function from all places
where it is used (function decls, method decls,
and function literals).
Includes some minor fixes/additions of missing links.
Based closely on Russ' proposal.
Fixes#65.
R=rsc, r, iant, ken, bradfitz
CC=golang-dev
https://golang.org/cl/7415050
Replacement for CL 7370053 which attempted to make fallthrough's
syntactically a part of switch statements. Because they may be
labeled, fixing that CL completely would require too much spec
surgery.
Fixes#4923.
R=r, iant, rsc, ken
CC=golang-dev
https://golang.org/cl/7416048
This is documenting the status quo. The previous cleanup
added this language as an implementation restriction, but
at least for now it is really part of the language proper.
Fixes#4605.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7305071
The gc compilers already behave this way. It was an explicit
decision during the very long constant design discussions,
but it appears not to have made it into the spec.
Fixes#4398.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7313069
The spec is not clear about whether this is allowed or not,
but both compilers allow it, because the reflect implementation
takes advantage of it. Document current behavior.
Fixes#4679.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7303064
The spec talks explicitly about rune literals but the
respective production is still called char_lit for
historic reasons. Updated the two occurences.
Fixes#4602.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/7070048
A composite literal may be parenthesized when
used as operand for the unary operator &.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6996053
This is language change. It is a backward-compatible
change but for code that relies on a run-time panic
when calling delete on a nil map (unlikely).
Fixes#4253.
R=rsc, r, iant, ken, bradfitz, rogpeppe
CC=golang-dev
https://golang.org/cl/6909060
We have been using all three terms "indices", "indexes",
and "index expressions" indiscriminatly for index values.
With this change, "index" refers to an index value,
"indices" is the plural of "index", and "index expression"
refers to an array, slice, or map indexed by an index: a[x].
R=r, rsc, iant, ken, mtj
CC=golang-dev
https://golang.org/cl/6912056
The spec didn't preclude invalid type assertions and
type switches, i.e., cases where a concrete type doesn't
implement the interface type in the assertion in the first
place. Both, the gc and gccgo compiler exclude these cases.
This is documenting the status quo.
Also:
- minor clean up of respective examples
- added sentence about default case in select statements
Fixes#4472.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6869050
Also:
- 'for' statements with a range clause do not accept send-only
channels
- '_, _ = range ch' is not equivalent to "_ = range ch" if ch
is a channel (rewriting the latter to the former leads to
an invalid range clause).
These clarifications document the status quo.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/6874053
1) Built-ins are restricted like for expression statements.
This documents the status quo.
2) Calls cannot be parenthesized. The spec is not clear. gccgo
permits it already, gc doesn't. Be explicit in the spec.
Fixes#4462.
R=rsc, iant, r, ken, lvd
CC=golang-dev
https://golang.org/cl/6861043
We have the notion of a PackageName, not package identifier.
As is, it could construed that imports that rename a package
don't have an "imported package identifier" but a local one.
R=r, rsc, iant, ken, dsymonds
CC=golang-dev
https://golang.org/cl/6858049
This is an attempt at making the interaction between
these three constructs clearer. Specifically:
- return statements terminate a function, execute deferred
functions, return to the caller, and then execution
continues after the call
- panic calls terminate a function, execute deferred
functions, return to the caller, and then re-panic
- deferred functions are executed before a function _returns_
to its caller
The hope is that with this change it becomes clear when a
deferred function is executed (when a function returns),
and when it is not (when a program exits).
R=r, rsc, iant, ken, iant
CC=golang-dev
https://golang.org/cl/6736071
Both gc and gccgo always checked this for constant
expressions but the spec only mentions run-time
exceptions.
This CL also requires that constant divisors
must not be zero in non-constant integer expressions:
This is consistent with the spirit of the most
recent changes and it is consistent with constant
expressions. We don't want to specify the effect for
non-integer expressions (f/0.0 where f is a float or
complex number) because there the result f/g is not
further specified if a non-constant g is 0.
R=r, rsc, iant, ken, andybalholm, iant
CC=golang-dev
https://golang.org/cl/6710045
This is a language change: Until now, the spec required run-
time panics for some of these errors. Note that gc and gccgo
implemented this inconsistently, and that both compilers already
reported compile-time errors in some cases. This change makes
make() behave along the same vein as index expressions.
This addresses the spec aspect of issue 4085.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6725053
At the moment, gc and gccgo report compile-
time errors for certain constant indexes that
are out of bounds. The spec however requests
a run-time panic for out-of-bounds indexes
(http://tip.golang.org/ref/spec#Indexes).
Document the status quo.
Fixes#4231.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6699048
Proposed new text to make matters clearer. The existing text was
unclear about the state of result parameters when panicking.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/6653047
It's already there but only in the "for instance" and so not
clear enough: deferred functions run after
the result parameters are updated.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6631058
Also: Be explicit what operator means with respect to conversion types.
The parenthesis requirement is a language change. At the moment,
literal function types in conversions that cannot possibly be
followed by a '(' don't need parentheses. For instance:
func(int)int(x) -> same as (func(int)int)(x)
func()()(x) -> same as (func())(x)
but:
func(int)(x) -> could be func(int)x {...}
Fixes#4109.
R=rsc, r, iant, ken, iant
CC=golang-dev
https://golang.org/cl/6584065
Also: Adjust prose in Conversions section
to be consistent.
This is a backward-compatible syntax change.
For a discussion see issue 2568.
Fixes#2568.
Fixes#4123.
R=golang-dev, r, iant, rsc
CC=golang-dev
https://golang.org/cl/6572049
Function and method calls are valid expression statements,
but calling certain built-in functions is not permitted.
Enumerate the built-ins.
Also: unsafe.Offsetof permits parenthesized selectors as
arguments.
This is simply documenting existing compiler behavior
(both gc and gccgo agree).
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6498138
Both gc and gccgo permit calls such as unsafe.Sizeof(42). The
spec only permits variable arguments. This is a (backward-compatible)
spec change reflecting the status quo. Seems preferrable over
restricting the compilers.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6494140
Strings happen to be represented similarly to
byte slices internally, but they don't quite
behave like them: While strings can be indexed,
sliced, and have their len() taken like byte
slices, string elements are not addressable,
make() and cap() is not supported, range loops
operate differently, and they are immutable (and
thus behave like values rather then references).
Fixes#4018.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6503116
The (and not) arguably sounds like it is trying to say something - and not what?.
Just an idea, won't be hurt if it gets rejected.
R=gri, dsymonds, r
CC=golang-dev
https://golang.org/cl/6498115
After further deliberation, let's back down to the Unicode proposal.
Ignoring aBOMinations anywhere means that things like
grep unsafe *.go
might fail because there's a BOM in the middle: unBOMsafe.
R=golang-dev, rsc, 0xjnml, gri, bradfitz
CC=golang-dev
https://golang.org/cl/6490091
No changes to the meaning, just clearer language and more
examples, including illegal rune and string literals.
In particular, "character literal" and "character constant"
are now called "rune literal" and "rune constant" and the
word "character" always refers to the source text, not
program values.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/6448137
- point out difference between selectors and qualified identifiers
- differentiate between illegal selectors and run-time panics
- use "indirect" as opposed to "dereference" consistently
- add extra links
Fixes#3779.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6326059
- receiving from a closed channel returns immediately
- in the ,ok form, the 2nd result is of type bool, not
just boolean (gc and ggcgo agree).
Per dsymonds' suggestion.
R=r, rsc, ken, iant, dsymonds
CC=golang-dev
https://golang.org/cl/6333057
They have been deleted from package unsafe.
Also delete their appearance in exp/types.
Fixes#3338.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5847056
- Define what it means for two identifiers to be unique.
- The current spec is incorrect about exported
identifiers: for instance, it excluded fields
of non-exported types of exported variables
from being exported. It is easier to leave
the detailed specification away and let the
rest of the spec govern access of exported
identifiers.
- The current spec is incorrect about qualified
identifiers: It simply required that an identifier
be exported to be valid in a qualified identifier.
However, qualified identifiers can only access
exported identifiers declared in the package
block of the imported package.
Fixes#1551.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/5711043
- more idiomatic examples of pointer types
- show use of _ in examples of function types
- remove "legal:" qualification in examples
for consistency
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5711054
When we first wrote the method set definition, we had long
discussions about whether method sets applied to all types
or just named types, and we (or at least I) concluded that it
didn't matter: the two were equivalent points of view, because
the only way to introduce a new method was to write a method
function, which requires a named receiver type.
However, the addition of embedded types changed this.
Embedding can introduce a method without writing an explicit
method function, as in:
var x struct {
sync.Mutex
}
var px *struct {
sync.Mutex
}
var _, _ sync.Locker = &x, px
The edits in this CL make clear that both &x and px satisfy
sync.Locker. Today, gccgo already works this way; 6g does not.
R=golang-dev, gri, iant, r
CC=golang-dev
https://golang.org/cl/5702062
Or, depending on your point of view, make the
comparisons satisfy any surrounding boolean type.
Also, fix a few foo_bar -> fooBar in code fragments.
Fixes#2561.
R=golang-dev, r, bradfitz, gri, iant, kevlar
CC=golang-dev
https://golang.org/cl/5671096
Drop reference to "machine type." Specify that integer
overflow must be an error. Drop requirement that exponent
must be 128 bits--that's a lot. Clarify that floating point
expressions may be rounded, including intermediate values.
This is a reworking of https://golang.org/cl/5577068/ .
Fixes#2789.
R=r, rsc, r, gri, ken, ken, iant
CC=golang-dev, remyoudompheng
https://golang.org/cl/5655049
The paragraph describing the ellipses presents the horizontal ellipsis
in two different fonts and at least on my screen they look too different.
Switch to a consistent rendering.
Of small steps are great journeys undertaken.
R=golang-dev, rsc, dsymonds, gri
CC=golang-dev
https://golang.org/cl/5650055
Other wordings are possible but defining this as one
of the ways to proceed means we don't have to add
language about this to the description of select.
Fixes#2825.
R=golang-dev, gri, r
CC=golang-dev
https://golang.org/cl/5643062
Document that indirection through a nil pointer will panic.
Explain function invocation.
This section will need more work, but it's a start.
Fixes#1865.
Fixes#2252.
R=rsc, iant, r
CC=golang-dev
https://golang.org/cl/5532114
This allows HTML pages to specify arbitrary data in a header:
<!--{
"Title": "The page title",
...
}-->
replacing the old style comments:
<!-- title The page title -->
R=gri, rsc, r, bradfitz, dsymonds
CC=golang-dev
https://golang.org/cl/5532093
- define "0-sized"
- add clarifying sentence to pointer comparison
- removed notion "location" which was used only in pointer comparisons
and which was never defined
Fixes#2620.
R=r, rsc, iant
CC=golang-dev
https://golang.org/cl/5528053
Several places mentioned tokens spanning "multiple lines"
which is not a well-defined term in the spec; newline is.
R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/5490046
This change guarantees that whether the line ending convention
when the source is created includes carriage returns is irrelevant
to the value of the string. See issue 680.
The compilers do not yet implement this.
R=golang-dev, adg, r, gri, rsc, iant
CC=golang-dev
https://golang.org/cl/5491043
Also, clarify when interface comparison panics and
that comparison to nil is a special syntax rather than
a general comparison rule.
R=r, gri, r, iant, cw, bradfitz
CC=golang-dev
https://golang.org/cl/5440117
This is a spec correction, not a language change.
The implementations have behaved like this for years
(and there are tests to that effect), and elsewhere in
the spec true and false are defined to be untyped
boolean constants.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5477047
This has always been true, but we lost it from the spec
somewhere along the way, probably when we disallowed
the general 'pointer to anything sliceable' slice case.
R=gri
CC=golang-dev
https://golang.org/cl/5437121
The allowed conversions before and after are:
type Tstring string
type Tbyte []byte
type Trune []rune
string <-> string // ok
string <-> []byte // ok
string <-> []rune // ok
string <-> Tstring // ok
string <-> Tbyte // was illegal, now ok
string <-> Trune // was illegal, now ok
Tstring <-> string // ok
Tstring <-> []byte // ok
Tstring <-> []rune // ok
Tstring <-> Tstring // ok
Tstring <-> Tbyte // was illegal, now ok
Tstring <-> Trune // was illegal, now ok
Update spec, compiler, tests. Use in a few packages.
We agreed on this a few months ago but never implemented it.
Fixes#1707.
R=golang-dev, gri, r
CC=golang-dev
https://golang.org/cl/5421057
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
This is true of the existing implementations, and I think
it is an important property to guarantee.
R=golang-dev, r, borman, r
CC=golang-dev
https://golang.org/cl/5321058
This is not a language change.
Added paragraphs specifying which conversions
yield results that are constants.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/4515176
This is (indirectly) a language change. Per e-mail discussion
on golang-dev.
Fixes#1943.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/4581058
- Added some additional examples.
- 6g appears to implement this semantics already.
Fixes#658.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/4538119
Note: This is not a spec change.
The spec was not clear on the result type of
constant shift expressions. Made it more
explicit and added additional examples.
Also: Remove paragraph on send expressions (they
are statements, now).
Fixes#1708.
R=rsc, r, iant, r
CC=golang-dev
https://golang.org/cl/4517074
This CL proposes some subtle language changes
in an attempt to clarify the semantics of range
clauses and simplify uses of maps.
- nil maps behave like empty maps; but attempting
to set a value in a nil map causes a run-time panic
- nil channels are never ready for communication;
sending or reading from a nil channel blocks forever
- if there is only one index iteration variable in a
range clause and len(range expression) would be a constant,
the range expression is not evaluated.
(was discrepancy with len/cap before)
- the notion of what is a constant expression len(x)
for (pointer to) arrays x has been generalized and
simplified (can still be syntactically decided)
(before: more restrictive syntactic rule that was not
consistently implemented)
Fixes#1713.
R=r, rsc, iant, ken2, r2, bradfitz, rog
CC=golang-dev
https://golang.org/cl/4444050
No language change.
- added a few examples with parentheses
- added a corresponding sentence to assignments
(this explicitly permits: (_) = 0, currently allowed by 6g,
gofmt, but marked as an error by gccgo).
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4446071
The CL introduces inconsistencies with respect to
the use of parentheses/grouping of receive operations.
««« original CL description
spec: narrow syntax for expression and select statements
This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057
»»»
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4444080
This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057
Computer people have an agglutinating streak that I like to resist.
As a time of execution: run time.
As an adjective: run-time.
As a noun: run-time support/code/library.
Signed,
Mr. Pedant.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4252048
- added an example to Type declarations section clarifying the
situation brought up with issue 1324
- slightly re-ordered paragraphs in Types section
- added separate heading for method set section and refer to it
from elsewhere in the spec
- no language changes
R=rsc, r, iant, ken2, r2
CC=golang-dev
https://golang.org/cl/4145043
Removed most of the detailed examples about handing panics
from the go spec since it's now covered by Effective Go.
R=r, rsc, iant, ken2
CC=golang-dev
https://golang.org/cl/4128058
This change makes it legal to pass a struct value as receiver
outside the package declaring the struct even if the respective
struct type has non-exported fields.
This is a backwards-compatible language change motivated by the
fact that it is already possible to circumvent the assignment
restriction when calling methods through interfaces (see issue
1402).
R=r, rsc, iant, ken2
CC=golang-dev
https://golang.org/cl/3926044
Prior to this CL, there were two requirements about the
package name main.
1. The package that sits at the root of the import graph
(the one where program execution begins)
must be named main.
2. No other package in the program can be named main.
This CL only removes requirement #2, which can be done
without changing any other Go documentation.
The new wording and formatting is such that removing
requirement #1 can be done by deleting a single line,
but making that change is explicitly outside the scope
of this CL, because it would require changes to other
documentation at the same time.
R=gri, r, gri1
CC=golang-dev
https://golang.org/cl/4126053
These are syntactical changes to better reflect the communication
operator's new status in the language.
- sending to a channel is now done via a send statement
- there is no binary communication operation anymore which
leads to a reduction of the number of precedence levels
from 6 to 5 (yeah!)
- small semantic change: since a send operation is not part
of the expression syntax anymore, a <- send operator is
binding weaker than any other operator now
- receiving from a channel is done as before via the unary
receive expression
- communication clauses in select statement now can contain
send statements or receive expressions
R=rsc, r, iant, ken2, gri1
CC=golang-dev
https://golang.org/cl/3973051
Close of closed channel panics.
Receive from closed channel never panics,
even if done repeatedly.
Fixes#1349.
Fixes#1419.
R=gri, iant, ken2, r, gri1, r2, iant2, rog, albert.strasheim, niemeyer, ejsherry
CC=golang-dev
https://golang.org/cl/3989042
The default float type is not very useful but for the most basic applications.
For instance, as it is now, using the math package requires conversions for float
variables (the arguments for math functions are usually float64). Typical real
applications tend to specify the floating point precision required.
This proposal removes the predeclared types float and complex. Variable declarations
without type specification but with constant floating point or complex initializer
expressions will assume the type float64 or complex128 respectively.
The predeclared function cmplx is renamed to complex.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/3423041
- use math.Sqrt instead of Math.sqrt
- use float64 for Point fields to match math.Sqrt
- distinguish between Point and Point3D for clarity
- add alignment sizes for complex types
R=r, rsc, iant, ken2
CC=golang-dev
https://golang.org/cl/3420041
Added a "return" to the end of an example which previously threw a compile error if used.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/3052041
Consistency argument: A valid Go program should
remain valid after stripping leading and trailing
whitespace. This was not true so far if the last
text in the source was a line comment.
R=iant, ken2, r, rsc, r2
CC=golang-dev
https://golang.org/cl/2906041
For elements which are themselves composite literals, the type may
be omitted if it is identical to the element type of the containing
composite literal.
R=r, rsc, iant, ken2
CC=golang-dev
https://golang.org/cl/2661041
Background: The current spec is imprecise with respect to the parsing ambiguity
for composite literals: It says that the ambiguity arises when the TypeName form
of the LiteralType is used. The following code:
if (B) {} ...
is not using the TypeName form (but the parenthesized TypeName form) and thus
could be interpreted as:
if ((B){}) ...
instead of
if B {} ...
Both compilers and gofmt choose the latter interpretation. One could fix the
spec by making the clause regarding the parsing ambiguity more precise ("...using
the _possibly parenthesized_ TypeName form of the LiteralType..."). The alternative
(chosen here) is to simply disallow parenthesized literal types. Except for a single
test case (test/parentype.go) there appears to be no Go code under $GOROOT containing
parenthesized literal types. Furthermore, parentheses are never needed around a
literal type for correct parsing.
R=golang-dev
CC=golang-dev
https://golang.org/cl/1913041
Matthew Dempsky
Robert Griesemer
Shenghou Ma
Brad Fitzpatrick
David Symonds
Rob Pike
Robin Eklind
Andrew Gerrand
Ian Lance Taylor
Dmitriy Vyukov
Emil Hessman
Mihai Borobocea
Robert Hencke
Russ Cox
Shenghou Ma
Oling Cat
Rémy Oudompheng
Matthew William Jibson
Hong Ruiqi
Jeremy Jackins
Stefan Nilsson
Christopher Wedgwood
Charles L. Dorian
Luuk van Dijk
Nigel Tao
Anthony Martin
Gustavo Niemeyer
Anschel Schaffer-Cohen
Peter Mundy
Joe Poirier
Scott Lawrence
Stephen Ma