Skip to content

G
golang
Switch branch/tag
  1. 24 May, 2014 2 commits
  3. 23 May, 2014 1 commit
  5. 22 May, 2014 2 commits
    • Robert Griesemer's avatar
      spec: explicitly disallow blank methods in interface types · 2c83f1ea
      Robert Griesemer authored 
      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
      2c83f1ea
    • Russ Cox's avatar
      doc/go1.3.html: change uintptr to integer in unsafe.Pointer section · 8d8dab34
      Russ Cox authored 
      The key property here is what the bit pattern represents,
not what its type is. Storing 5 into a pointer is the problem.
Storing a uintptr that holds pointer bits back into a pointer
is not as much of a problem, and not what we are claiming
the runtime will detect.

Longer discussion at
https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98370045
      8d8dab34
  7. 21 May, 2014 18 commits
  9. 20 May, 2014 17 commits