[go-nuts] Go multiple return language design question.

On Thursday, October 23, 2014 3:00:05 PM UTC-7, andrewc...@gmail.com wrote:


var y,z = tup // implicit splitting of tuple.

On Friday, October 24, 2014 11:32:12 AM UTC+13, cm...@golang.org wrote:
Curious about implicitly splitting a tuple. What is the value x, y, and z
in

`var x,y,z = tup, tup`

for your example?

On Thursday, October 23, 2014 3:00:05 PM UTC-7, andrewc...@gmail.com
wrote:

On Thu, Oct 23, 2014 at 3:00 PM, wrote:
Regarding the language design, was there a reason why Go multiple return is
a special case? It seems quite natural to introduce a tuple type e.g.

var tup (int,string) = (5,"foobar")

var x = tup[1] // Inferred as string type.

var y,z = tup // implicit splitting of tuple.

func multiReturn() (int,error) {
return 0,nil
}

Were there any problems with something like that? e.g. grammar ambiguities,
confusion etc. I'm not suggesting a change now, but wondering if this was
considered and discarded.

On Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor wrote:

On Thu, Oct 23, 2014 at 3:00 PM, <andrewc...@gmail.com <javascript:>>
wrote:
As far as I can recall the approach you describe was never seriously
considered. Generalized tuples have a considerable overlap with
struct types.

I think we did consider permitting tuples, essentially an implicit
struct, for channel sense, since that is a case where it could be
convenient in practice.

type C chan (int, string)
func F(c C) {
c <- 1, 2
x, y := <-c
}

But of course that conflicts with the optional multiple results of a
channel receive.

Ian

On Friday, 24 October 2014 02:04:02 UTC+3, andrewc...@gmail.com wrote:
Thanks for the insight. I'm asking because I'm investigating my own low
level language design with C interop in mind, based on Go syntax, So I
appreciate understanding what I can improve upon or change without entirely
losing the spirit of what makes Go an elegant language.

On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
PS. remember that the language goal is to solve problems, but not having
as many features as possible.

Pick yourself a criteria on which basis you add features. e.g.
1. It must, at least, solve 3 actual (real-world) problems
2. When it solves a problem, there must not be a better way to do it.

Currently you were talking about tuples without mentioning any problems it
actually solves.

+ egon

On Fri Oct 24 2014 at 4:06:23 AM wrote:

Thanks for the advice. I'm not adding features lightly and wish to remove
many too. One interesting example was Rob Pike(iirc) mentioning x := 123
syntax being redundant and confusing to newbies vs var x = 123. Is this a
feature of Go which would be better omitted in derived languages? Many
features of C itself were deemed unnecessary or detrimental and removed by
Go to the benefit of everyone. (? operator, assignment expressions, non
boolean values in if conditions, implicit type conversion etc.) I
appreciate this attention to detail and focus on useful features very much.
Hence my wish to bring some of the Go ideals (and aesthetics) to some areas
C dominates (GC implementations, low memory areas, OS kernels etc) in an
ABI compatible way.
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Sunday, October 26, 2014 8:43:58 PM UTC-7, Matt Harden wrote:
Personally, I think the use case for tuples is simpler, more readable
code, compared to creating a struct, array or slice every time you need a
compound value. Just as multiple return values is more concise and readable
than returning a struct, the same goes for all other uses of tuples, and
supporting general tuples would make a hypothetical language more
orthogonal compared to "only" multiple return values as in Go.

For Go itself, I think it would be nice if struct types were type inferred
the same way basic types are today. So the code below would give x the
anonymous type struct{i int, s string, i64 int64}.

x := struct{i: 3, s: "three", i64: int64(-1)}

On Sun Oct 26 2014 at 11:35:23 PM Brendan Tracey wrote:


That doesn't work, but the following does work:

x := struct {i int; s string; i64 int64}{3, "three", -1}

It does work

f := func(){}

creates a function with no inputs and no outputs.

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

On Oct 26, 2014, at 9:41 PM, Matt Harden wrote:

Yes, I'm aware of what does work now. In both cases you are explicitly declaring the types of the values. Type inference could allow the types to be left out of the code. IMO this makes things more readable in some cases. Your func example does not demonstrate type inference.

On Sun Oct 26 2014 at 11:35:23 PM Brendan Tracey wrote:


On Sunday, October 26, 2014 8:43:58 PM UTC-7, Matt Harden wrote:
Personally, I think the use case for tuples is simpler, more readable code, compared to creating a struct, array or slice every time you need a compound value. Just as multiple return values is more concise and readable than returning a struct, the same goes for all other uses of tuples, and supporting general tuples would make a hypothetical language more orthogonal compared to "only" multiple return values as in Go.

For Go itself, I think it would be nice if struct types were type inferred the same way basic types are today. So the code below would give x the anonymous type struct{i int, s string, i64 int64}.

x := struct{i: 3, s: "three", i64: int64(-1)}


That doesn't work, but the following does work:

x := struct {i int; s string; i64 int64}{3, "three", -1}

I would expand type inference to func values also. This is not because I think it's too hard to type the types, but because I think it would make code easier to read and understand, just as it does today with basic types.

It does work

f := func(){}

creates a function with no inputs and no outputs.

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

On Oct 26, 2014, at 9:45 PM, Brendan Tracey wrote:

var x struct{i int; s string; i64 int64} = struct{i int; s string; i64 int64}{3, "three", -1}

and

var f func() = func(){}

would be explicitly declaring the types of the variables.

On Monday, 27 October 2014 05:43:58 UTC+2, Matt Harden wrote:
Personally, I think the use case for tuples is simpler, more readable
code, compared to creating a struct, array or slice every time you need a
compound value. Just as multiple return values is more concise and readable
than returning a struct, the same goes for all other uses of tuples, and
supporting general tuples would make a hypothetical language more
orthogonal compared to "only" multiple return values as in Go.

For Go itself, I think it would be nice if struct types were type inferred
the same way basic types are today. So the code below would give x the
anonymous type struct{i int, s string, i64 int64}.

x := struct{i: 3, s: "three", i64: int64(-1)}

I would expand type inference to func values also. This is not because I
think it's too hard to type the types, but because I think it would make
code easier to read and understand, just as it does today with basic types.

Now someone is going to argue that I should use / create some kind of
editor extension or preprocessor to do the type inference for me. That's no
good because the point is making the code easier to read, and the transform
would likely be one-way. Also I only think this should be used in cases
where it actually would improve readability - complex structs should not be
created this way.


On Fri Oct 24 2014 at 4:06:23 AM <andrewc...@gmail.com <javascript:>>
wrote:

On Monday, October 27, 2014 3:43:58 AM UTC, Matt Harden wrote:

Personally, I think the use case for tuples is simpler, more readable
code, compared to creating a struct, array or slice every time you need a
compound value. Just as multiple return values is more concise and readable
than returning a struct, the same goes for all other uses of tuples, and
supporting general tuples would make a hypothetical language more
orthogonal compared to "only" multiple return values as in Go.

For Go itself, I think it would be nice if struct types were type inferred
the same way basic types are today. So the code below would give x the
anonymous type struct{i int, s string, i64 int64}.

x := struct{i: 3, s: "three", i64: int64(-1)}

I would expand type inference to func values also. This is not because I
think it's too hard to type the types, but because I think it would make
code easier to read and understand, just as it does today with basic types.

Now someone is going to argue that I should use / create some kind of
editor extension or preprocessor to do the type inference for me. That's no
good because the point is making the code easier to read, and the transform
would likely be one-way. Also I only think this should be used in cases
where it actually would improve readability - complex structs should not be
created this way.


On Fri Oct 24 2014 at 4:06:23 AM <andrewc...@gmail.com <javascript:>>
wrote:

On Mon Oct 27 2014 at 3:24:22 AM Tahir wrote:

Would it work for built-in types only or would it work for every type ?

If it is only for built-in types, it only saves a few keystrokes (but
takes probably many more keystrokes to implement).

If for every type, it degrades readability in larger codebase or even just
at the package level with types being defined in one file while being used
in another.

The only time I think tuples could be handy would be as method receivers.
And even then that's just a thought I had because I'm used to method
chaining. It's not a particular pain point of mine though.
Thanks for the advice. I'm not adding features lightly and wish to remove
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Fri, Oct 24, 2014 at 12:00 AM, wrote:
Regarding the language design, was there a reason why Go multiple return is
a special case?