Will Go ever have assignment by slice unpacking? Why or why not?

[Meester Guy Person]

Hey, I'm new to this forum, so I'm sure this topic has come up before.  Have read different things on the subject and I'm still not clear why assignment by unpacking a slice (or array) would be a problem.  Maybe someone can explain.  Say we have something like the following:

one, two, three := []string{"one", "two", "three"}...

I'm using the "..." here as a way of denoting that we want to unpack the slice into these variables.  Could be anything though.
So we know here what our types are, and can still check this at compile time, so we're still type safe, and as long as we
have the same number of items on each side, shouldn't be a problem.

Even if we don't have the same number, things could still be handled.  Say we have the following two scenarios:

one, two := []string{"one", "two", "three"}...

and

one, two, three, four := []string{"one", "two", "three"}...

In the first instance, we could just throw out any extra slice members that don't have a variable to fill.  Don't see how that would cause any problems, as long as we know what to expect in the slice.  In the second instance, we can set "four" to nil, since there aren't enough values to fill it.  Much like the error handling idiom, we could then check those variables as needed and handle their "nil"-ness accordingly.

So I'm not really seeing any major disadvantages to implementing this in the language.  Is there some underlying reason why this has not or will not be done?

Thanks!

[Caleb Spare]

IMO, the two mismatched length cases are the reason this doesn't fit
into Go. You gave suggestions for what the behavior would be (1. ditch
the extra values and 2. fill in 'nil' [note that this actually doesn't
work -- strings cannot be nil, for instance -- but we could use a zero
value for the type]). However, these sort of "make a best-effort guess
at what the programmer intended and keep trucking" semantics are not
really found in the language. Go wants you to be explicit about what
you intend.

It could work for arrays but their usage is relatively rare.

Note that you can always do

s := []string{"one", "two", "three"}
one, two, three := s[0], s[1], s[2]

-Caleb

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[minux]

Please discuss this on the golang-nuts mailing list. Thanks.

The short answer is that we want to keep the language simple, and this feature isn't strictly necessary,

just a convenience.

[j...@fastmail.fm]

I really would like to thank you and the Go team for this practically unique approach to language design. I get sad when so many things have to keep adding more and more sugar for every little annoyance until the language spec is 100 pages double-sided. I’m guilty myself as a Schemer (macros for everything are oh-so-tempting), and having Go to turn to from time to time is priceless. Please, please keep up the good work!

Sorry if this wasn’t the right list to reply in, but I just really felt the need to let you folks know.

--
  Jonathan Chan
  j...@fastmail.fm

--

[Rob Pike]

Thanks for saying that. Your mail cheered me up.

-rob

[Dmitri Shuralyov]

I probably don't say this enough (or at all), but I feel the same way.

In fact, Go's simplicity and power through few orthogonal features is quite likely the the thing I like the most about it.

There are many attempts where people feel adding language complexity is an improvement, so it's really nice to see one opposite approach that turns out to work so well.

[Meester Guy Person]

Sorry, was not aware that that existed.  Is there a list of mailing lists somewhere that details what kinds of post are most appropriate for each?

Also, FYI, reason this came up is that I was attempting to create a passthrough function with a variable number of arguments and hence variable number of return arguments.  This obviously can't be done through the current return mechanism, but can through a list, but it's messy and would require checking each index before assigning.  Although not strictly necessary as you say, a construct like this would save a lot of unnecessary coding and might be worth implementing.

Will look for the other mailing list.  Thanks for the reply.