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
