FAQ
Hello,

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.

--
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.

Search Discussions

  • Cmang at Oct 23, 2014 at 10:32 pm
    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:


    var y,z = tup // implicit splitting of tuple.
    --
    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.
  • Andrewchamberss at Oct 23, 2014 at 10:46 pm

    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:

    var y,z = tup // implicit splitting of tuple.
    Interesting thought, in my opinion perhaps if tuples existed then the comma
    operator would create them. So your example would be shorthand for var
    x,y,z = (tup,tup); So the comma operator creates a tuple of tuples, which
    would result in a compiler error as there is a tuple size mismatch.

    --
    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.
  • Ian Taylor at Oct 23, 2014 at 10:33 pm

    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.
    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

    --
    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.
  • Andrewchamberss at Oct 23, 2014 at 11:04 pm
    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 11:34:01 AM UTC+13, Ian Lance Taylor wrote:

    On Thu, Oct 23, 2014 at 3:00 PM, <andrewc...@gmail.com <javascript:>>
    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.
    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
    --
    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.
  • Egon at Oct 24, 2014 at 5:56 am

    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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.
  • Andrewchamberss at Oct 24, 2014 at 9:06 am
    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.
    On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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.
  • Matt Harden at Oct 27, 2014 at 3:43 am
    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 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.
    On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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.
    --
    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.
  • Brendan Tracey at Oct 27, 2014 at 4:35 am

    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.
  • Matt Harden at Oct 27, 2014 at 4:41 am
    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.
    --
    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.
  • Brendan Tracey at Oct 27, 2014 at 4:45 am
    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 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.
    --
    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.
  • Brendan Tracey at Oct 27, 2014 at 4:47 am
    I understand your point that a couple of characters could be saved for the struct. I do think both of my examples show the type of the new variable being inferred.
    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 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.
    --
    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.
  • Egon at Oct 27, 2014 at 7:31 am

    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.
    Can you show a real world example where this is the case? Where multiple
    return and/or explicit structs would become less readable?

    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:
    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.
    On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Tahir at Oct 27, 2014 at 8:24 am
    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.
    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:
    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.
    On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Matt Harden at Oct 27, 2014 at 1:20 pm
    Er... I need to think about this a bit more before replying. Thanks
    everyone for challenging what I thought I "knew", and especially egon for
    bringing me to earth by simply requesting a real world example. This is a
    great community.
    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.
    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 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.
    On Friday, October 24, 2014 6:56:53 PM UTC+13, egon wrote:
    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.
    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 Friday, October 24, 2014 11:34:01 AM UTC+13, Ian Lance Taylor 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.
    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
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
    --
    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.
  • Jan Mercl at Oct 24, 2014 at 6:24 am

    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?
    What do you mean by "special case"? Go function can have N inputs and
    M outputs. N, M are non negative integers. That's pretty general. In
    contrast, if N is unlimited and M is capped at 1 - now that's a
    special case, isn't it?

    -j

    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 23, '14 at 10:00p
activeOct 27, '14 at 1:20p
posts16
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase