release.2010-10-27
Andrew Gerrand
can update by running:
hg pull
hg update release
*** This release changes the encoding used by package gob.
If you store gobs on disk, see below. ***
The ARM port (5g) now passes all tests. The optimizer is not yet enabled, and
floating point arithmetic is performed entirely in software. Work is underway
to address both of these deficiencies.
The syntax for arrays, slices, and maps of composite literals has been
simplified. Within a composite literal of array, slice, or map type, elements
that are themselves composite literals may elide the type if it is identical to
the outer literal’s element type. For example, these expressions:
[][]int{[]int{1, 2, 3}, []int{4, 5}}
map[string]Point{“x”: Point{1.5, -3.5}, “y”: Point{0, 0}}
can be simplified to:
[][]int{{1, 2, 3}, {4, 5}}
map[string]Point{“x”: {1.5, -3.5}, “y”: {0, 0}}
Gofmt can make these simplifications mechanically when invoked with the
new -s flag.
The built-in copy function can now copy bytes from a string value to a []byte.
Code like this (for []byte b and string s):
for i := 0; i < len(s); i++ {
b[i] = s[i]
}
can be rewritten as:
copy(b, s)
The gob package can now encode and decode interface values containing types
registered ahead of time with the new Register function. These changes required
a backwards-incompatible change to the wire format. Data written with the old
version of the package will not be readable with the new one, and vice versa.
(Steps were made in this change to make sure this doesn’t happen again.)
We don’t know of anyone using gobs to create permanent data, but if you do this
and need help converting, please let us know, and do not update to this release
yet. We will help you convert your data.
Other changes:
* 5g, 6g, 8g: generate code for string index instead of calling function.
* 5l, 6l, 8l: introduce sub-symbols.
* 6l/8l: global and local variables and type info.
* Make.inc: delete unnecessary -fno-inline flag to quietgcc.
* arm: precise float64 software floating point, bug fixes.
* big: arm assembly, faster software mulWW, divWW.
* build: only print "You need to add foo to PATH" when needed.
* container/list: fix Remove bug and use pointer to self as identifier.
* doc: show page title in browser title bar,
update roadmap.
* encoding/binary: give LittleEndian, BigEndian specific types.
* go/parser: consume auto-inserted semi when calling ParseExpr().
* gobuilder: pass GOHOSTOS and GOHOSTARCH to build,
write build and benchmarking logs to disk.
* goinstall: display helpful message when encountering a cgo package,
fix test for multiple package names (thanks Fazlul Shahriar).
* gotest: generate correct gofmt-formatted _testmain.go.
* image/png: speed up paletted encoding ~25% (thanks Brad Fitzpatrick).
* misc: update python scripts to specify python2 as python3 is now "python".
* net: fix comment on Dial to mention unix/unixgram.
* rpc: expose Server type to allow multiple RPC Server instances.
* runtime: print unknown types in panic.
* spec: append built-in (not yet implemented).
* src: gofmt -s -w src misc.
update code to use copy-from-string.
* test/bench: update numbers.
* websocket: fix short Read.
Apologies if we missed anyone in the above list. We appreciate all your help.
To see a full list of changes between this and the previous release,
after updating, run:
hg log -r release.2010-10-20:release.2010-10-27
Enjoy.
Andrew
Hans Stimer
friend.
Paulo Pinto
Eric Eisner
> The syntax for arrays, slices, and maps of composite literals has been
> simplified. Within a composite literal of array, slice, or map type, elements
> that are themselves composite literals may elide the type if it is identical to
> the outer literal’s element type. For example, these expressions:
> [][]int{[]int{1, 2, 3}, []int{4, 5}}
> map[string]Point{“x”: Point{1.5, -3.5}, “y”: Point{0, 0}}
> can be simplified to:
> [][]int{{1, 2, 3}, {4, 5}}
> map[string]Point{“x”: {1.5, -3.5}, “y”: {0, 0}}
Could it be possible to extend this literal syntax to channel input?
p := make(chan struct{string;int})
p <- struct{string;int}{"abc", 123}
could be
p := make(chan struct{string;int})
p <- {"abc", 123}
Brad Fitzpatrick
Steven
I had the exact same thought. However, without adding a way to
structurally decompose structs in a single statement (rather than N
statements), I think the utility of an unnamed struct channel is
limited.
A better alternative would seem to be multiple value channels, but
this is currently blocked by val, ok syntax.
Ps- notice that the fields of that struct are private, so your channel
would be useless outside the package of origin.
tiny_dust
better by allowing these statement:
type Person struct{
name string
address Address
alias []string
}
type Address struct{
country string
city string
}
func main(){
p :=Person{name:"main name",
address:{country:"country1",
city: "city1"},
alias:["aname1","aname2"]}
}
(1)compiler can infer the type of‘address’ field in composite
literal.
(2)slice,map and array literal seems good if the we replace ‘{‘ ‘}’
with ‘[]’(for readability in composite literal):
then we’ll get closer to json format, it could be more brief but the
language is still static typed.
Andrew Gerrand
> (1)compiler can infer the type of‘address’ field in composite
> literal.
This is a good (and popular) suggestion. The short story is that we're
proceeding carefully as we're wary of reducing comprehensibility when
programming "in the large". See this post:
http://groups.google.com/group/golang-nuts/msg/170b1242cbc6e18c
> (2)slice,map and array literal seems good if the we replace ‘{‘ ‘}’
> with ‘[]’(for readability in composite literal):
This seems like a gratuitous change to me.
Andrew
Steven
tiny_dust
> > (2)slice,map and array literal seems good if the we replace ‘{‘ ‘}’
> > with ‘[]’(for readability in composite literal):
>
> This seems like a gratuitous change to me.
>
give different syntax to different semantic
suggestion (2) make sensel only when suggestion (1) is accepted.
otherwise it is really valueless, we can forget it.
maybe it's just my taste :)
Gustavo Niemeyer
> I would like to suggest (*T){v}. The syntax T{v} denotes a value of type T
> with an element v, which is an accurate description of a pointer, and so the
> syntax could logically be extended to pointers. A pointer is just a
> reference to single (typed) element, just as a slice is a reference to an
> ordered, uniformly typed set of elements.
> This is relevant to the present discussion, because you could then write
> []*int{ {5}, {6}, {7} }
> It also suggests a potential syntax for:
> []*Point{ &Point{1, 2}, &Point{3, 4} }
> This being:
> []*Point{ {{1, 2}}, {{3, 4}} }
With no intentions of being harsh, none of that makes sense to me
(literally, I have no idea about where the syntax comes from).
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
Steven
A pointer is, essentially, a box where you can put exaclty one thing.
The thing in the box is the element of the box. The box is a reference
type, like a slice, so people with different copies of the same box
see the same element inside the box. A pointer can be uninitialized
(ie nil) just like any other reference type.
To prove that I'm not just making stuff up with this "element of a
pointer" stuff, check out:
http://golang.org/pkg/reflect/#PtrType
The thing a pointer points to is known as it's element.
Composite literal syntax (T{}) makes a value of type T, with it's
elements set to the values between the {}. This doesn't make sense for
types without elements. However, a pointer type *does* have elements
(specifically, 1 element). So, it would make sense to be able to use
composite literal syntax to make a pointer with it's set of elements
initialized to the set of values between the {}.
p1 := (*int){ 5 } // an int pointer with it's 1 element initialized to
the value 5
p2 := (*int){} // an int pointer with it's 1 element initialized to
the 0 value for int, equivalent to new(int)
p3 := (*int)(nil) // an uninitialized int pointer
Q: But doesn't a *composite* literal imply that the type has more than
one element?
A: No. Composite literals work equally well for [0]byte, [1]byte,
struct{}, and struct{ X int }. The important part is that the type is
a composite of it's elements. The number of elements is irrelevant.
Gustavo Niemeyer
I see what you mean. This doesn't feel semantically correct, though,
because a pointer's value is not a variable itself, but the *address*
of a variable. Given the semantics you describe, I'd expect this to be
spelled as (*int){&value}, which, of course, is not very useful.
Steven
No, by your argument, a slice initialiser would be []int{array[:]}.
The semantics of a composite literal indicate that the *element(s)* of
the value go between the {}, not the value itself. The element of a
*int is an int. Therefore the value between the {} in (*int){value}
would be of type int, and would indicate the value that the pointer
points to.
