Go 1

3162 views
Skip to first unread message

Russ Cox

unread,
Oct 6, 2011, 9:08:39 AM10/6/11
to golang-nuts
See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
Please post comments in this thread. Thanks.

André Moraes

unread,
Oct 6, 2011, 9:41:58 AM10/6/11
to golang-nuts
The new "Go" tool will have more features than goinstall + make
Or will only replace those?

If it will only replace why not keep goinstall as the tool name?


--
André Moraes
http://andredevchannel.blogspot.com/

André Moraes

unread,
Oct 6, 2011, 9:43:48 AM10/6/11
to golang-nuts
Another thing I forgot to put in the last post:

The exp package will still live in the tip and will be removed only on
the "Go N" versions?

Brian Ketelsen

unread,
Oct 6, 2011, 9:44:18 AM10/6/11
to golang-nuts

On Oct 6, 2011, at 9:08 AM, Russ Cox wrote:

> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.


Is the plan to incrementally change the current tree to meet these goals? How many releases (weekly/monthly or otherwise) do you envision between now and Go 1? The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error. I think it would be beneficial to make these structural changes as soon as possible. The other changes are more subtle.

Brian


Brandon Mercer

unread,
Oct 6, 2011, 9:46:32 AM10/6/11
to golang-nuts
Doesn't gofix solve most of these issues for users even if they're
following a short term release cycle? I've not seen any issue in
things being maintained the way they are now.

J.L.vanderZwan

unread,
Oct 6, 2011, 9:48:49 AM10/6/11
to golang-nuts
In the document there's a minor typo at "multiple assignment": the x
should be an m.

Reliability is important, so this is a good development. Other than
that, I know that I don't know enough about programming to weigh in on
the discussion as to what should be in Go 1 - I'll just keep watching
on the sidelines.

On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.

roger peppe

unread,
Oct 6, 2011, 10:02:12 AM10/6/11
to r...@golang.org, golang-nuts
On 6 October 2011 14:08, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

LGTM

particular +1s to: composite literals, map deletion, no function equality,
composite map keys, package renaming.

not sure about: error.Value as a name, go/types noncompletion,

i'll miss gotry, although i doubt anyone else will.

Vincent Vanackere

unread,
Oct 6, 2011, 10:02:08 AM10/6/11
to r...@golang.org, golang-nuts
On Thu, Oct 6, 2011 at 15:08, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.
>

equality

The current language does not define equality on struct and array values.  It does define equality on function and map values.  Function equality is problematic in some contexts and map equality compares pointers, not the maps’ content.  Only types with defined equality can be used as map keys.

Go 1 will define equality on struct and array values composed from fields on which equality is also defined (element-wise comparison).

This one will be a great improvement. If I understand the implication correctly, it will make mappings much more powerful and in most cases remove the need to use an encoding scheme (typically to a string value) for complex keys.  :-)
 
 It will remove equality on function and map values except for comparison with nil.

However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?

Vincent

Florian Weimer

unread,
Oct 6, 2011, 10:14:38 AM10/6/11
to golang-nuts
* Russ Cox:

> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.

Regarding composite literals, can they used for unnamed parameters, as
in:

type Entry struct {
Name string
Value float64
}

var f func(*Entry)

...
f({Name: "pi", 3.14})

?

I still think it would make sense to aim for more consistent error
handling (callers always have to check the error return).

yy

unread,
Oct 6, 2011, 11:00:49 AM10/6/11
to r...@golang.org, golang-nuts
I'd like to know what is the reason to add the "delete" builtin
instead of the syntax which has been proposed before: m[k] = _

I just think the number of builtins should be minimized, but I may be
missing something. (By the way, the same syntax could be applied to
closing channels too: c <- _, then the restriction to close
receive-only channels would be evident.)

Also, I don't really like error.Value, but I don't have a better
proposal and I agree os.Error was not right.

Anyway, I'd like to say that in general terms I like very much the
suggested changes and the idea of a stable release. In particular, I
find the go command very nice and the solution to shadowing return
values quite original.


--
- yiyus || JGL .

Message has been deleted

Eleanor McHugh

unread,
Oct 6, 2011, 11:11:15 AM10/6/11
to golang-nuts
On 6 Oct 2011, at 14:08, Russ Cox wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.

My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
if _, ok := reality.(Reasonable); !ok { panic(reality) }

unread,
Oct 6, 2011, 11:11:29 AM10/6/11
to golang-nuts
On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

The Go 1 preview document says:

"Go 1 will continue to exclude equality for slices. (In the general
case it is infeasible.)"

I don't understand the reasoning behind this. Is the reason
performance, or complexity of implementation, or something else?

Paulo Pinto

unread,
Oct 6, 2011, 11:22:08 AM10/6/11
to golang-nuts
Not to raise a big discussion about it, but I miss generics on the Go
1 list.

Having them added afterwards might create issues, assuming that they
will "eventually"
be in Go.

--
Paulo

Peter Bourgon

unread,
Oct 6, 2011, 11:24:21 AM10/6/11
to r...@golang.org, golang-nuts
> The Go 1 release will include a new tool “go” that will replace both goinstall and make.

For me, this is by far the most exciting part of the proposal. I'd
love to hear as much detail as possible about this new tool.
Specifically, I'm interested in how the authors propose to address
dependencies of packages on both runtimes and other packages. Also, it
would be great to see a clear definition of where "go"-installed
packages can possibly reside (if that would differ from the current
implementation).

Mateusz Czapliński

unread,
Oct 6, 2011, 11:31:34 AM10/6/11
to golang-nuts
On Oct 6, 3:41 pm, André Moraes <andr...@gmail.com> wrote:
> The new "Go" tool will have more features than goinstall + make
> Or will only replace those?
> If it will only replace why not keep goinstall as the tool name?

At least for the Windows port, this is a fairly fortunate change, as
it will effectively work around the special treatment Windows gives to
executables containing 'install' or 'setup' in name. (Really funny
thing, this.)

As of the rest, it's an interesting reading. I enjoy especially
'deletion from map', 'return with named arguments', 'Go tool' and
'official Windows binaries'. Also the fact that some pretty big
changes are planned at all, and Go 1 is to emerge soon.
I pity lack of announced plans for a solution to the problem with :=
assignment.

regards
/Mateusz Czaplinski.

Gustavo Niemeyer

unread,
Oct 6, 2011, 11:32:37 AM10/6/11
to r...@golang.org, golang-nuts
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

Fantastic news there. Exciting times.

As a detail, for the append improvement it'd be nicer to see a fix for
issue 2204 instead, since it's a generic desire to be able to handle
an underlying string byte-by-byte without incurring in gratuitous
allocation. The issue describes a few different cases in addition to
the append support that come from the same problem.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.

tux21b

unread,
Oct 6, 2011, 11:44:24 AM10/6/11
to golan...@googlegroups.com, r...@golang.org
> A later version of Go will change rune to be an alias for int32, which will make it
> reasonable to change int to be 64 bits.

Why have you postponed this change?

> As part of that effort we plan to set up a separate dashboard for repositories showing
> the build and test status against different Go versions.

That sounds great! It's probably my favorite :) Have you considered tagging packages
on the dashboard with "approved" if they are reviewed by golang-dev (e.g. graphics,
leveldb-go, etc) and perhaps "recommended" for packages which are maintained
somewhere else, but are checked/used by gophers regularly (e.g mgo and maybe gorilla?).

-christoph

tiny_dust

unread,
Oct 6, 2011, 10:52:13 AM10/6/11
to golang-nuts
i think compiler should check error automaticly when user ignore it
by "_"

example:
f,_:=os.Open("xxx")
=>
f,err01:=os.Open("xxx");check(err01) //func check(err os.Error)
{if err!=nil{panic(err)}}


it is bad idiom to ignore error by "_" without this feature.
this feature will improve robust of error handling.

in many situations(not all), error handling is a crosscutting
concerns,such as deployment problem,programming bugs.
normal logic need not handle these things everywhere. (os.Error is
like the CheckedException of Java)

On 10月6日, 下午10时14分, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Russ Cox:
>
> > Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.

Sebastien Binet

unread,
Oct 6, 2011, 12:15:06 PM10/6/11
to golang-nuts


On Oct 6, 5:22 pm, Paulo Pinto <paulo.jpi...@gmail.com> wrote:
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.
+1

>
> Having them added afterwards might create issues, assuming that they
> will "eventually"
> be in Go.
+1

-s

chris dollin

unread,
Oct 6, 2011, 12:40:03 PM10/6/11
to Paulo Pinto, golang-nuts
On 6 October 2011 16:22, Paulo Pinto <paulo....@gmail.com> wrote:
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.

I can't see that for a Go 1 "early next year" that there's enough time
to devise, implement, and soak-test generics for Go.

Much as I would like to have them myself ...

Chris

--
Chris "allusive" Dollin

Douwe Gelling

unread,
Oct 6, 2011, 12:37:02 PM10/6/11
to golang-nuts
Looks good, although:

"container/vector - not in Go 1
Scheduled for deletion."

Maybe I'm the only one using this package, but why is it removed? I
really
like being able to use a list that automatically grows. Or will there
be some
replacement?

Riton

unread,
Oct 6, 2011, 12:40:58 PM10/6/11
to golan...@googlegroups.com
Will string be implemented as []rune then ?
We could finally use :

s:= "世界"
len(s) // 2
s[1] // 世
range s



Go1 looks really nice !

Jesse McNelis

unread,
Oct 6, 2011, 12:45:53 PM10/6/11
to Douwe Gelling, golang-nuts

Been stuck under a rock for a while? anyway, the append() built-in
offers all the functionality of container/vector for any type of slice.

http://golang.org/doc/go_spec.html#Appending_and_copying_slices
http://code.google.com/p/go-wiki/wiki/SliceTricks

Andrew Gerrand

unread,
Oct 6, 2011, 12:48:11 PM10/6/11
to golan...@googlegroups.com
The built-in append and copy functions make container/vector largely redundant. See:


Andrew

yy

unread,
Oct 6, 2011, 12:49:24 PM10/6/11
to tiny_dust, golang-nuts
2011/10/6 tiny_dust <ustc....@gmail.com>:

> i think compiler should check error automaticly when user ignore it
> by "_"

Errors are just values. The compiler doesn't know that what you are
ignoring is an error.

Douwe Gelling

unread,
Oct 6, 2011, 12:52:54 PM10/6/11
to golang-nuts
On Oct 6, 5:48 pm, Andrew Gerrand <a...@golang.org> wrote:
>
> The built-in append and copy functions make container/vector largely
> redundant. See:
>
> http://code.google.com/p/go-wiki/wiki/SliceTricks
>
> Andrew

Whoop yeah, sorry. Disregard that then :)

chris dollin

unread,
Oct 6, 2011, 12:52:50 PM10/6/11
to golan...@googlegroups.com
On 6 October 2011 17:40, Riton <henri....@gmail.com> wrote:
> Will string be implemented as []rune then ?

I doubt it. That would make most strings a lot fatter than they need be.
You can cast to and from []int already if you need to -- that will just become
[]rune.

> We could finally use :
> s:= "世界"
> len(s) // 2
> s[1] // 世

(s[0], not s[1])

> range

range works on strings already.


--
Chris "allusive" Dollin

Andrew Gerrand

unread,
Oct 6, 2011, 12:56:32 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 6:41:58 AM UTC-7, André Moraes wrote:
The new "Go" tool will have more features than goinstall + make
Or will only replace those?

If it will only replace why not keep goinstall as the tool name?

The "go" command has already been designed. You can see its usage/help text here:


As you can see, it does more than just installation, so "goinstall" isn't really an apt name anymore.

Andrew

Ugorji Nwoke

unread,
Oct 6, 2011, 12:57:39 PM10/6/11
to golan...@googlegroups.com
There's utf8.String type for that. Also, range already allows you loop over the runes of a string. I really like as string is a sequence of bytes, but there's available support for going across code points if you want to.

Riton

unread,
Oct 6, 2011, 1:04:10 PM10/6/11
to golan...@googlegroups.com
Don't you find it inconsistent that range that is supposed to iterate over the elements of the string implemented as a []byte returns you runes instead of bytes ?

Andrew Gerrand

unread,
Oct 6, 2011, 1:06:59 PM10/6/11
to golan...@googlegroups.com


On Thursday, October 6, 2011 6:44:18 AM UTC-7, Brian Ketelsen wrote:

Is the plan to incrementally change the current tree to meet these goals?  How many releases (weekly/monthly or otherwise) do you envision between now and Go 1?  The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error.  I think it would be beneficial to make these structural changes as soon as possible.  The other changes are more subtle.

We intend to introduce these changes over a series of weeklies. The major structural changes will be made in weekly snapshots of their own. Gofix will update user code automatically in most cases.

The next release will be the Go 1 release candidate.

Andrew

  

Ugorji Nwoke

unread,
Oct 6, 2011, 1:18:26 PM10/6/11
to golan...@googlegroups.com
I think, if you want to iterate over a slice of bytes, convert the string to a slice of bytes. ie I expect the following to do different things:
s := "abc"
for idx, val := range s { ... } // iterate over the runes of a string s (special case for a string, just like there's different special-case semantics for a map)
for idx, val := range []byte(s) { ... } // iterate over a byte slice (as a typical slice iteration does)

In practice, it's pretty intuitive and novel.

Riton

unread,
Oct 6, 2011, 1:28:23 PM10/6/11
to golan...@googlegroups.com
range is defined as a way to iterate over the elements, therefore it seems weird that accessing the element of string and iterating over the string produce differents types (byte and rune respectively)

chris dollin

unread,
Oct 6, 2011, 1:32:41 PM10/6/11
to golan...@googlegroups.com

Strings aren't implemented as []byte.

Even if they were, implementing something as []byte doesn't demand that
all accesses be to bytes.

The inconsistency is that s[x] gets you raw bytes but range gets you codepoints.
It's a compromise that keeps strings slim and [] access fast. Most of
the time there's
no problem, and there are no problem-free constructs ...

chris dollin

unread,
Oct 6, 2011, 1:35:01 PM10/6/11
to Eleanor McHugh, golang-nuts
On 6 October 2011 16:11, Eleanor McHugh <ele...@games-with-brains.com> wrote:
> On 6 Oct 2011, at 14:08, Russ Cox wrote:
>> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
>> Please post comments in this thread.  Thanks.
>
> My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.

When does one type-cast anonynous functions?

Or do you mean that an anonymous function comes with a heavy-weight
func ... syntax? It's not clear to me that you could leave it out and preserve
Go's type-safety.

Andrew Gerrand

unread,
Oct 6, 2011, 1:48:02 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 6:43:48 AM UTC-7, André Moraes wrote:
Another thing I forgot to put in the last post:

The exp package will still live in the tip and will be removed only on
the "Go N" versions?

Yes. The exp/ directory will still be in tip, but deleted from the release branch.

Andrew

Andrew Gerrand

unread,
Oct 6, 2011, 1:52:38 PM10/6/11
to golan...@googlegroups.com, r...@golang.org


On Thursday, October 6, 2011 7:02:08 AM UTC-7, Vincent wrote: 
 It will remove equality on function and map values except for comparison with nil.

However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?
 
Function equality is rarely used and expensive to implement.  It causes problems in dynamic libraries (based on
experience with C) and it also prevents us from avoiding allocations when creating trivial closures.

Map equality is currently defined as map pointer equality, which isn't very useful (we couldn't find any code that uses it). By removing equality on maps we can redefine map equality to something more useful at a later stage.

Andrew

unread,
Oct 6, 2011, 1:52:31 PM10/6/11
to golang-nuts
Consider the following explanation:

It is currently possible to easily iterate over the individual bytes
of "[]byte" or "string" using a for loop:

for i:=0; i<len(s); i++ {
fn(s[i])
}

On the other hand, should range over a Go string be byte-oriented (as
opposed to rune-oriented), there wouldn't be an easy method of how to
iterate over the runes of a string. Iterating over the runes would
look like this:

for i:=0; i<len(s); {
rune, size := utf8.DecodeRune(s[i:])
fn(rune)
i += size
}

That it is *longer* (less succinct) than:

for _, rune := range s {
fn(rune)
}

The reason behind the choice to have "range s" iterate over runes is
that the language *already* has a succinct method of how to iterate
over the bytes of a string (see the 1st code snippet). Without "range
s" returning runes, there wouldn't exist a succinct method of how to
iterate over the characters of a Go string.

Andrew Gerrand

unread,
Oct 6, 2011, 1:56:01 PM10/6/11
to golan...@googlegroups.com, r...@golang.org
On Thursday, October 6, 2011 8:00:49 AM UTC-7, yiyus wrote:
I'd like to know what is the reason to add the "delete" builtin
instead of the syntax which has been proposed before: m[k] = _

I just think the number of builtins should be minimized, but I may be
missing something. (By the way, the same syntax could be applied to
closing channels too: c <- _, then the restriction to close
receive-only channels would be evident.)

We want to keep different concepts in Go orthogonal.
m[x] = _ is cute but gives _ two unrelated meanings.
A new function name is clear and does not interfere with other parts of the language.

Andrew

André Moraes

unread,
Oct 6, 2011, 2:05:38 PM10/6/11
to golan...@googlegroups.com
> The "go" command has already been designed. You can see its usage/help text here:
>
> http://code.google.com/p/go/source/browse/src/cmd/go/script.txt
>
> As you can see, it does more than just installation, so "goinstall" isn't really an apt name anymore.

After reading that text the name change really makes sense.

As a suggestion a "pack" command could be placed there.

It will use the same logic for list, but instead of just listing it
will copy to some dir and pack as a zip/tar.gz/etc...

Of course that the user can just use the list command with some other
tool to achive the same result.

--
André Moraes
http://andredevchannel.blogspot.com/

Riton

unread,
Oct 6, 2011, 2:11:49 PM10/6/11
to golan...@googlegroups.com
I understand the reasons behind this behavior. Isn't there a way (maybe more verbose) to have a consistent behavior when using range and [] ? After all, when I read somewhere else in this thread that _ is a wrong choice as a "delete operator" because it would break the consistency with its current use, I think that this range/[] incoherence is worse.

In other languages you would range/iterate over something like a RuneIterator that would enforce the consistency. Isn't there a go-way to achieve that ?

Julian Phillips

unread,
Oct 6, 2011, 2:16:26 PM10/6/11
to r...@golang.org, golang-nuts
On Thu, 6 Oct 2011 09:08:39 -0400, Russ Cox wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.

There's a lot of nice stuff in there.

However, I just can't bring myself to like error.Value. It seems such
an ... icky name for something that I find myself using all the time
when writing library code.

Can't we promote it further to a builtin type "error"?

error.New could be a cast instead - i.e. error("foo")

If that isn't acceptable, how about a "lang" package for such things?
Then we could have lang.Error and lang.NewError. This could also be a
home for things like lang.Version ...

--
Julian

yy

unread,
Oct 6, 2011, 2:17:33 PM10/6/11
to golan...@googlegroups.com, r...@golang.org
2011/10/6 Andrew Gerrand <a...@golang.org>:

> We want to keep different concepts in Go orthogonal.
> m[x] = _ is cute but gives _ two unrelated meanings.

I was thinking in _ as some sort of /dev/null, so the two meaning were
not so unrelated, at least in my head.

> A new function name is clear and does not interfere with other parts of the
> language.

Fair enough. I just wanted to know the reason the other option was
discarded. Thanks for your answer.

And by the way, thanks for asking. You did not only make your
(mid-term?) plans public, you asked for opinion. That's very kind of
you.

Florian Weimer

unread,
Oct 6, 2011, 2:39:47 PM10/6/11
to yy, tiny_dust, golang-nuts
* yy:

It might make sense to error out if *any* return value is ignored, not
just os.Error. Explicitly ignoring errors when there are other result
values does not appear common. Most reports to the mailing list
seemed to involve functions which return nothing but an error.

But this is only part of the problem. Currently, for io.Reader and
similar interfaces, you have to check the non-error value before the
error-value, and for most other functions, you have to check the error
value before anything else. This leads to bugs.

Miki Tebeka

unread,
Oct 6, 2011, 2:45:03 PM10/6/11
to golan...@googlegroups.com, r...@golang.org
Looks good. Some suggestions:

1. Make testing.T an interface
2. Allow conversion of []T to []interface{} (as in http://golang.org/doc/go_faq.html#convert_slice_of_interface)
3. Add sort.GenericSort(items interface{}, func cmp(a, b interface{}) int)

David Roundy

unread,
Oct 6, 2011, 3:08:40 PM10/6/11
to ⚛, golang-nuts
On Thu, Oct 6, 2011 at 8:04 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
> On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
>> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.

>> Please post comments in this thread.  Thanks.
>
> The Go 1 preview document says:
>
> "Go 1 will continue to exclude equality for slices. (In the general
> case it is infeasible.)"
>
> I do I understand the reasoning behind this. Is the reason
> performance, or complexity of implementation, or something else?

I would presume because the value of slices can change, and it
normally doesn't make sense to copy them, which makes them not so
useful as map keys. On the other hand, if you *did* copy slices, then
I don't see any particular problem with having them as map keys under
the same constraints.

David

David Roundy

unread,
Oct 6, 2011, 3:15:54 PM10/6/11
to r...@golang.org, golang-nuts
I have a couple of reservations.

One is regarding the lack of specification for rejection due to
shadowing of result variables:

> Go 1’s compilers will reject a return statement without arguments when any of the result variables has been shadowed. This rule will not be defined in the language spec, by analogy with the rules about when a function is missing a return statement. Not specifying the behavior, while enforcing with the compilers, makes it easier to adjust the rules as we continue to explore this area of the Go language.

I can understand the appeal of this (allowing for future refinements
to the "fatal warnings" algorithms), but it seems like it seriously
undermines the utility of having a specification: if it's not
possible to determine whether a given program is valid from the
specification seems like a real problem, particularly in a stable
release. Once go 1 is released, I presume that these checks will be
frozen in stone... or at least the compiler will only become more
liberal. Otherwise valid go 1 programs will fail to compile under go
1.1 or later. If this is the case, it'd be nice to have careful
wording in the spec that indicates which programs will *not* fail.

I guess a commitment that programs that compile under go 1 are
guaranteed to compile in go 1.x. On the other hand, that still makes
the compiler itself a de facto language specification, which seems
inelegant and potentially dangerous (e.g. what happens if gccgo and gc
are found to differ on a given case). Probably this won't happen, but
bugs in compilers have been known to be found in the past...

David

barnex

unread,
Oct 6, 2011, 3:25:22 PM10/6/11
to golang-nuts
This is great news.

+1 for the equality

+1 for the long-term stability. As a Go developer I don't mind
gofixing my code from time to time. But sometimes people want to
contribute to C or python parts of my project and they need Go to
compile the entire source tree. For them, it's not so trivial to
install the correct Go release since the project sometimes lags the Go
revisions.

Thanks for the effort!
-Arne.

Jonathan Amsterdam

unread,
Oct 6, 2011, 3:25:34 PM10/6/11
to golang-nuts
> When does one type-cast anonynous functions?

I think she means that you need to specify the arg and return types
for anonymous functions:

func applyTwice(f func(int)int, x int) int { return f(f(x)) }

...
applyTwice(func(i int) int { return i+1}, 3)


The compiler could do type inference here so that the call could look
something like

applyTwice(func(i) { return i+1 }, 3)

or, since the func keyword might be confusing here (since the syntax
for arg and return values are so different):

applyTwice(\i{return i+1}, 3)

> Or do you mean that an anonymous function comes with a heavy-weight
> func ... syntax? It's not clear to me that you could leave it out and preserve
> Go's type-safety.

You could only use the concise form if the type of the function was
available in some other way.

Paulo Pinto

unread,
Oct 6, 2011, 3:28:19 PM10/6/11
to golang-nuts
I know. I just wanted to stress it.

On 6 Okt., 18:40, chris dollin <ehog.he...@googlemail.com> wrote:
> On 6 October 2011 16:22, Paulo Pinto <paulo.jpi...@gmail.com> wrote:
>
> > Not to raise a big discussion about it, but I miss generics on the Go
> > 1 list.
>
> I can't see that for a Go 1 "early next year" that there's enough time
> to devise, implement, and soak-test generics for Go.
>
> Much as I would like to have them myself ...

Kyle Consalus

unread,
Oct 6, 2011, 3:36:53 PM10/6/11
to golan...@googlegroups.com
Another more convenient and slower way here: 
https://gist.github.com/1268398

(See the test for usage. Not at all well tested.)

Evan Shaw

unread,
Oct 6, 2011, 3:38:20 PM10/6/11
to golang-nuts
Great news! I'm glad to see some effort towards stabilizing even if
version 1 won't have every feature I want. :) I am happy with most of
the changes in the Go 1 plan, though.

I might be jumping the gun, but where will development effort be
focused after the release? Will it be aimed towards improving the
release or will development on "Go 2" begin immediately? Somewhere in
between?

- Evan

Jonathan Amsterdam

unread,
Oct 6, 2011, 3:35:59 PM10/6/11
to golang-nuts
I'm glad that the map deletion syntax is going, but I have an issue
with the delete function. Namely, it's not a function: it doesn't
evaluate its argument. I understand that many of the built-in
functions are special -- some take types as arguments, and the types
of some cannot be expressed in Go -- but delete would be the only one
that doesn't evaluate a non-type argument. There's a simple fix for
that:

delete(m, x)

Is the cuteness of writing delete(m[x]) worth the confusion and
weirdness?

Michael Shields

unread,
Oct 6, 2011, 3:46:54 PM10/6/11
to r...@golang.org, golang-nuts
I like the plan to create a "rune" type alias, but I'm concerned about waiting until "a later version" to make int 64-bit.  Slices larger than 2**31 elements are increasingly reasonable, and over the lifetime of Go 1 will become more so.  Is there a reason that using too much space for runes until they can become int32s is a major concern?

Jonathan Amsterdam

unread,
Oct 6, 2011, 4:36:57 PM10/6/11
to golang-nuts
I'm excited that I will be able to use types like struct { x, y int }
as map keys. That is a step forward.

My concern is that a lot of types will now be comparable by "==", and
some of those shouldn't be -- any type for which elementwise equality
is wrong. E.g., types with pointers, or where only part of a field is
used.

I suppose you are going to tell me to make at least one field in my
struct unexported, and then equality, like copying, will be turned off
outside of the package. Fine. I'm not happy about linking behavior to
exportability, but I guess that's for another thread.

But I'm curious why you didn't go in another direction: why not say a
type T can be a map key if it defines Hash() int and Equals(T) bool
(or is one of the builtin types that supports ==)?

Steven Blenkinsop

unread,
Oct 6, 2011, 5:37:56 PM10/6/11
to Jonathan Amsterdam, golang-nuts
On Thu, Oct 6, 2011 at 4:36 PM, Jonathan Amsterdam <j...@google.com> wrote:
My concern is that a lot of types will now be comparable by "==", and
some of those shouldn't be -- any type  for which elementwise equality
is wrong. E.g., types with pointers, or where only part of a field is
used.

There's always going to be ways of misusing user defined types, which means it would often be nice to be able to control their behaviour more. However, coming up with an elegant way to do that would be difficult, so it seems we're stuck with whatever compromises the Go team comes up with for now.

Go 1 will allow abbreviating a composite literal of the form &T{...} initializing a value of type *T, by omitting the &T.

Ah. This kills my dreams of someday having a pointer composite literal, since the syntax would conflict. Oh well. Nobody was jumping on the idea anyways, though I would still prefer &{...} just in case. The reason it would have been nice is for those times when you need a pointer to a copy of a value, whether because the value is not addressable, or some other reason.

I do think the name error.Value needs to be rethought, it just doesn't look right for something so extensively used. Maybe error.T, thus solidifying a convention...

On Thu, Oct 6, 2011 at 1:35 PM, chris dollin <ehog....@googlemail.com> wrote:
Or do you mean that an anonymous function comes with a heavy-weight
func ... syntax? It's not clear to me that you could leave it out and preserve
Go's type-safety.

Well, as has been mentioned, you could use type inference. The problem is serendipity of function parameters, the same argument for requiring the type in composite literal arguments to functions. A change in the parameters could create an undetectable logic error. However, I'm not entirely sure serendipity would be a huge problem for anonymous functions. Also, consider that you can infer the type of return values and then use them in code. Inferring the types of parameters of anonymous functions wouldn't really be all that different.

Anyways, if you want a more concise way of representing both type and parameter name bindings, something like:

->FuncType(i, s){ return i * s.M() }
, as opposed to:
func (i int, s MyStructType) int { return i * s.M() }

could work to reduce the visual noise, plus you could allow the dropping of the type in certain circumstances. However, one of the stated goals isn't to be debating new language features ;).

Jim Whitehead II

unread,
Oct 6, 2011, 5:49:00 PM10/6/11
to Jonathan Amsterdam, golang-nuts

I have to echo this. Even though it's not implemented as a function,
it appears to be a function call and its very 'magical'. It says
'delete the entry x from map m' but it does it in a way that looks
like we're deallocating the value contained at m[x]. It looks a but
too much like a free() to me.

delete(m, x) is a great suggestion for making this syntax clear and
easy to read and write. It says to delete the value associated with
the key x in the map m.

- Jim

Andrew Gerrand

unread,
Oct 6, 2011, 5:51:22 PM10/6/11
to golan...@googlegroups.com, r...@golang.org
On Thursday, October 6, 2011 8:44:24 AM UTC-7, tux21b wrote:
> A later version of Go will change rune to be an alias for int32, which will make it
> reasonable to change int to be 64 bits.

Why have you postponed this change?


On Thursday, October 6, 2011 12:46:54 PM UTC-7, mshields wrote:
I like the plan to create a "rune" type alias, but I'm concerned about waiting until "a later version" to make int 64-bit.  Slices larger than 2**31 elements are increasingly reasonable, and over the lifetime of Go 1 will become more so.  Is there a reason that using too much space for runes until they can become int32s is a major concern?


The rune alias is both a useful name (like byte) and the transition plan for int.

The official way to refer to a Unicode code point in Go 1 is rune. Referring to a Unicode code point using int will work in Go 1 but will be deprecated, so not guaranteed to work over the lifetime of Go 1.

Developers can update their code to use rune at their leisure (we will provide a way to identify places where it is needed), and then in some later release, possibly a Go 1.x, we will make rune be an alias for int32.  At that point we will be able to widen int to 64 bits on 64-bit platforms without affecting the in-memory size of rune sequences.

Andrew

Andrew Gerrand

unread,
Oct 6, 2011, 5:52:00 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 8:11:29 AM UTC-7, ⚛ wrote:
On Oct 6, 3:08 pm, Russ Cox <r....@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

The Go 1 preview document says:

"Go 1 will continue to exclude equality for slices. (In the general
case it is infeasible.)"

I don't understand the reasoning behind this. Is the reason
performance, or complexity of implementation, or something else?

Since slices and maps can refer to themselves indirectly, general equality would require cycle detection in order to be guaranteed to finish.  That's more expensive than we'd like.

Andrew
 

Andrew Gerrand

unread,
Oct 6, 2011, 5:52:35 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 7:14:38 AM UTC-7, Florian Weimer wrote:

Regarding composite literals, can they used for unnamed parameters, as
in:

        type Entry struct {
                Name string
                Value float64
        }

        var f func(*Entry)

        ...
        f({Name: "pi", 3.14})

?

I still think it would make sense to aim for more consistent error
handling (callers always have to check the error return).

No, a composite literal parameter to a call cannot be shortened.

Andrew

Richard Crowley

unread,
Oct 6, 2011, 6:12:31 PM10/6/11
to Julian Phillips, r...@golang.org, golang-nuts
> However, I just can't bring myself to like error.Value.  It seems such an
> ... icky name for something that I find myself using all the time when
> writing library code.
>
> Can't we promote it further to a builtin type "error"?
>
> error.New could be a cast instead - i.e. error("foo")
>
> If that isn't acceptable, how about a "lang" package for such things?  Then
> we could have lang.Error and lang.NewError.  This could also be a home for
> things like lang.Version ...

+1 for lang.Error, lang.NewError, etc.

I'm saddened that "uses of operating system errors (for example, the
uses of os.EINVAL and os.ERANGE by package strconv) will be
discouraged." Error numbers are very attractive to me because they're
machine-actionable and can be propagated outside the Go runtime.
Within Go, type switches on values that implement os.Error are great
but syntactically tedious.

Use of plain-string errors like os.stringError should be what's discouraged.

Dave Cheney

unread,
Oct 6, 2011, 6:24:13 PM10/6/11
to r...@golang.org, golang-nuts
Hi Russ,

The plan for Go version 1 look great.

On Fri, Oct 7, 2011 at 12:08 AM, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.


> Please post comments in this thread.  Thanks.

I have two comments on the proposal, both of with have been raised
already in this thread:

1. map delete syntax - I agree that adding a new builtin to replace
the old map delete syntax is a good improvement, but I think Jonathan
and Jim have a good point that delete(m[k]) is a little strange. What
is the type of the single argument passed to delete, m, or k? I think
delete(map, key) fits pattern established by append and copy. There is
also the issue of someone new to the language attempting to use
delete() as some form of free(). A two argument delete builtin would
make such incorrect usage a syntax error.

2. error.Value - I agree completely that os.Error needs addressing but
am not sure that error.Value is a good replacement for the following
reasons.
* error.Value is 3 characters longer than os.Error, which is a small
footprint increase on disk, but does run contrary to Go's emphasis on
concise syntax and variable names. A possible replacement could be
error.E, which follows the pattern set by the testing package. However
this does not fully address my next point.
* import "error" removes error as a possible variable name. We saw
that identified during the development of exp/sql, which decided
against using the use of "db" as the package name for this reason.
* error.Value implies might imply that there are other types inside
the error package. While this probably isn't the case, it sets a
precident for a package that contains only a single interface type and
a few helper functions.
* While importing os, just to get the os.Error type may be overkill,
having to import the error package simply to return an error, which
most likely came from the function your package is calling, is just as
clunky.

I have two suggestions, which may or may not be feasable
* go.Error, in the package go. At least it's the same count as
os.Error, and does not consume error as a variable name. I am not sure
if this would conflict with the go statement.
* Some new type for errors, which itself is a built in alias for fmt.Stringer.

Cheers

Dave

Kyle Lemons

unread,
Oct 6, 2011, 7:42:07 PM10/6/11
to Andrew Gerrand, r...@golang.org, golang-nuts
I love a lot of the changes in here.  The only bike shed whose color I care enough to post about is error.Value.  My primary reason for this is that embedding one in your own error type now makes its name Value, as in the following:

type ParseError struct {
   line, char int
   file string
   error.Value
}

Reading code that uses it like the following looks a bit odd:

if p, ok := err.(*ParseError); ok {
   switch p.Value { // p.Error makes a lot more sense.
   case ...
   }
}

I think error.Error looks rather verbose (there may be other, better names), but would much prefer it to error.Value for the times where it does not appear directly with its package name.

But, it's not my choice, and this will be the last you hear from me about it.
~K