FAQ
Hi all, please be gentle as I am a brand new golanger :)

What do you think about the following syntax change, to make the return
value(s) visually separated from the returned error. I'm not sure what the
new symbol should be; I used :> below, but =: has a potentially pleasing
symmetry. I especially like how this proposal looks in the second case,
since it removes the need to type the error var name twice:


func MySqrt(f float64) (float64, error)

ret1 := MySqrt(-1) *:> err1*

if err1 != nil {

}

if ret2 := MySqrt(5) *:> err2 != nil* {

}






--
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/groups/opt_out.

Search Discussions

  • James Bardin at Apr 4, 2013 at 1:56 pm

    On Thursday, April 4, 2013 9:44:01 AM UTC-4, Eric Sampson wrote:
    Hi all, please be gentle as I am a brand new golanger :)

    What do you think about the following syntax change, to make the return
    value(s) visually separated from the returned error. I'm not sure what the
    new symbol should be; I used :> below, but =: has a potentially pleasing
    symmetry. I especially like how this proposal looks in the second case,
    since it removes the need to type the error var name twice:
    There's nothing special about the returned error. It doesn't have to be the
    second argument, nor does it need to be the last (you can return more than
    two things).

    if ret2 := MySqrt(5) *:> err2 != nil* {

    what's wrong with the standard:

    if ret2, err2 := MySqrt(5); err2 != nil {


    --
    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/groups/opt_out.
  • James Bardin at Apr 4, 2013 at 1:58 pm

    On Thu, Apr 4, 2013 at 9:56 AM, James Bardin wrote:

    it removes the need to type the error var name twice

    sorry, answered my second question, but the first point still stands.

    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 2:17 pm

    On Thursday, April 4, 2013 8:56:32 AM UTC-5, James Bardin wrote:
    There's nothing special about the returned error. It doesn't have to be
    the second argument, nor does it need to be the last (you can return more
    than two things).
    James, aside from enabling the cleaner syntax of the second case, the point
    of the proposal is that it *makes* something special about the returned
    error. By visually separating out returned errors from returned values,
    it's immediately obvious to someone reading other people's code which of
    the returns are values vs errors. Right now there is total flexibility -
    you can return errors anywhere in the return arguments and give them any
    name. When you're scanning Go code, aside from looking up the function
    declaration, the only thing telling you which return(s) is the error is the
    loose convention of naming them something like 'err' and the fact that they
    are immediately compared to nil.

    --
    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/groups/opt_out.
  • Rémy Oudompheng at Apr 4, 2013 at 10:42 pm

    On 2013/4/4 Eric Sampson wrote:
    On Thursday, April 4, 2013 8:56:32 AM UTC-5, James Bardin wrote:


    There's nothing special about the returned error. It doesn't have to be
    the second argument, nor does it need to be the last (you can return more
    than two things).
    James, aside from enabling the cleaner syntax of the second case, the point
    of the proposal is that it *makes* something special about the returned
    error. By visually separating out returned errors from returned values, it's
    immediately obvious to someone reading other people's code which of the
    returns are values vs errors.
    What's the point of that? Some people might want pointer variables to
    be coloured in pink and interface variables to be coloured in green to
    make it totally obvious... but for what purpose? Same thing here.
    Right now there is total flexibility - you can
    return errors anywhere in the return arguments and give them any name. When
    you're scanning Go code, aside from looking up the function declaration, the
    only thing telling you which return(s) is the error is the loose convention
    of naming them something like 'err' and the fact that they are immediately
    compared to nil.
    Errors are not always compared to nil. There's little point in
    returning errors if the only thing you do is comparing them to nil.
    Why do you need "something telling you which is the error"? What does
    it bring?

    Being called is enough to single out errors. If an error is not called
    err, either the author wants to indicate something particular
    (precisely singling out this variable), or has bad programming style.

    Using weird punctuation symbols (and using punctuation symbols at all,
    actually) brings more visual pollution than it singles things out.

    Rémy.

    --
    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/groups/opt_out.
  • Eric Sampson at Apr 5, 2013 at 3:47 am

    On Thursday, April 4, 2013 5:42:36 PM UTC-5, Rémy Oudompheng wrote:
    On 2013/4/4 Eric Sampson <eric.s...@gmail.com <javascript:>> wrote:
    On Thursday, April 4, 2013 8:56:32 AM UTC-5, James Bardin wrote:


    There's nothing special about the returned error. It doesn't have to be
    the second argument, nor does it need to be the last (you can return
    more
    than two things).
    By visually separating out returned errors from returned values, it's
    immediately obvious to someone reading other people's code which of the
    returns are values vs errors.
    What's the point of that? Some people might want pointer variables to
    be coloured in pink and interface variables to be coloured in green to
    make it totally obvious... but for what purpose? Same thing here.
    Hi Rémy, obviously the proposal has not turned out to be popular, but I
    just wanted to mention one thing regarding your above statement. As I
    understand things, the motivation for having a Go identifier's case
    determine/signal its visibility is not massively different from the
    motivation that I gave above. For example, I read this statement of Rob's<http://talks.golang.org/2012/splash.article#TOC_11.>
    :

    *... putting the visibility in the name rather than its type means that
    it's always clear when looking at an identifier whether it is part of the
    public API. After using Go for a while, it feels burdensome when going back
    to other languages that require looking up the declaration to discover this
    information.*


    All the best,
    Eric



    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 2:22 pm
    Also, replying to myself here, I called this proposal a syntax change but I
    should have called it an addition. I'm thinking that something like this
    could be added to the language as an optional syntax, working alongside the
    existing. That way existing code will notbreak, people could adopt the new
    usage over time, etc. Maybe it could even be added to gofmt if there was a
    way to automatically convert to the new syntax?

    --
    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/groups/opt_out.
  • Andy Balholm at Apr 4, 2013 at 3:53 pm
    Whenever someone says "a modest proposal," I think of Jonathan Swift. Your
    proposal is better than his, anyway :-)

    But I don't think you will find much interest in changes to Go's syntax at
    this point. Most people who read this list like the core language pretty
    much the way it is, and besides, we're in the feature freeze preparing for
    the Go 1.1 release.

    --
    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/groups/opt_out.
  • Hotei at Apr 4, 2013 at 4:57 pm
    Interesting proposal, but it runs against the grain in my opinion. What if
    I want to return two errors - or twenty - in addition to the "normal"
    return values? Maybe I have a function that operates on a vector and I
    want an error return for each element? Go as it currently exists lets me
    do this easily. With your proposal it would probably require another
    "special case". I think this is a case of "it's not broken..."
    On Thursday, April 4, 2013 9:44:01 AM UTC-4, Eric Sampson wrote:

    Hi all, please be gentle as I am a brand new golanger :)

    What do you think about the following syntax change, to make the return
    value(s) visually separated from the returned error. I'm not sure what the
    new symbol should be; I used :> below, but =: has a potentially pleasing
    symmetry. I especially like how this proposal looks in the second case,
    since it removes the need to type the error var name twice:


    func MySqrt(f float64) (float64, error)

    ret1 := MySqrt(-1) *:> err1*

    if err1 != nil {

    }

    if ret2 := MySqrt(5) *:> err2 != nil* {

    }





    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 5:20 pm

    On Thursday, April 4, 2013 11:56:58 AM UTC-5, Hotei wrote:
    Interesting proposal, but it runs against the grain in my opinion. What
    if I want to return two errors - or twenty - in addition to the "normal"
    return values? Maybe I have a function that operates on a vector and I
    want an error return for each element? Go as it currently exists lets me
    do this easily. With your proposal it would probably require another
    "special case". I think this is a case of "it's not broken..."
    Thanks for the thoughts Hotei. Could you show a little pseudo-code for the
    two cases that you mention? That would help me understand & discuss them.

    --
    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/groups/opt_out.
  • James Bardin at Apr 4, 2013 at 5:32 pm
    an obviously contrived example: http://play.golang.org/p/F6eCis7gGT
    On Thursday, April 4, 2013 1:20:05 PM UTC-4, Eric Sampson wrote:


    On Thursday, April 4, 2013 11:56:58 AM UTC-5, Hotei wrote:

    Interesting proposal, but it runs against the grain in my opinion. What
    if I want to return two errors - or twenty - in addition to the "normal"
    return values? Maybe I have a function that operates on a vector and I
    want an error return for each element? Go as it currently exists lets me
    do this easily. With your proposal it would probably require another
    "special case". I think this is a case of "it's not broken..."
    Thanks for the thoughts Hotei. Could you show a little pseudo-code for the
    two cases that you mention? That would help me understand & discuss them.
    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 5:55 pm

    On Thursday, April 4, 2013 12:32:39 PM UTC-5, James Bardin wrote:
    an obviously contrived example: http://play.golang.org/p/F6eCis7gGT
    On Thursday, April 4, 2013 1:20:05 PM UTC-4, Eric Sampson wrote:


    On Thursday, April 4, 2013 11:56:58 AM UTC-5, Hotei wrote:

    Interesting proposal, but it runs against the grain in my opinion. What
    if I want to return two errors - or twenty - in addition to the "normal"
    return values? Maybe I have a function that operates on a vector and I
    want an error return for each element? Go as it currently exists lets me
    do this easily. With your proposal it would probably require another
    "special case". I think this is a case of "it's not broken..."
    Thanks for the thoughts Hotei. Could you show a little pseudo-code for
    the two cases that you mention? That would help me understand & discuss
    them.
    Thanks James, that helps - I would have had to go read for a while to come
    up with that example. As I said I'm really new to the language :)

    In the case that you showed, my proposal would look like this:
    http://play.golang.org/p/UzgoAUdDnV




    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 5:55 pm
    Thanks James, that helps - I would have had to go read for a while to come
    up with that example. As I said I'm really new to the language :)

    In the case that you showed, my proposal would look like this:
    http://play.golang.org/p/UzgoAUdDnV
    On Thursday, April 4, 2013 12:32:39 PM UTC-5, James Bardin wrote:

    an obviously contrived example: http://play.golang.org/p/F6eCis7gGT
    On Thursday, April 4, 2013 1:20:05 PM UTC-4, Eric Sampson wrote:


    On Thursday, April 4, 2013 11:56:58 AM UTC-5, Hotei wrote:

    Interesting proposal, but it runs against the grain in my opinion. What
    if I want to return two errors - or twenty - in addition to the "normal"
    return values? Maybe I have a function that operates on a vector and I
    want an error return for each element? Go as it currently exists lets me
    do this easily. With your proposal it would probably require another
    "special case". I think this is a case of "it's not broken..."
    Thanks for the thoughts Hotei. Could you show a little pseudo-code for
    the two cases that you mention? That would help me understand & discuss
    them.
    --
    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/groups/opt_out.
  • James Bardin at Apr 4, 2013 at 6:05 pm

    On Thursday, April 4, 2013 1:55:50 PM UTC-4, Eric Sampson wrote:
    Thanks James, that helps - I would have had to go read for a while to come
    up with that example. As I said I'm really new to the language :)

    In the case that you showed, my proposal would look like this:
    http://play.golang.org/p/UzgoAUdDnV
    What I was getting at with my first reply, is that there's nothing special
    about returning an error type. Those returned object may not be represent
    exceptional states, or even related to the function called. I might just be
    passing them up the stack for logging.

    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 6:21 pm

    On Thursday, April 4, 2013 1:04:59 PM UTC-5, James Bardin wrote:

    What I was getting at with my first reply, is that there's nothing special
    about returning an error type. Those returned object may not be represent
    exceptional states, or even related to the function called. I might just be
    passing them up the stack for logging.
    Yup, I wasn't thinking that the two usages would be mutually exclusive. If
    one or more of your returned errors are non-exceptional, by all means treat
    them as normal returned variables. See here:
    http://play.golang.org/p/BRLuUGcreI

    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 6:27 pm

    On Thursday, April 4, 2013 1:21:37 PM UTC-5, Eric Sampson wrote:

    Yup, I wasn't thinking that the two usages would be mutually exclusive. If
    one or more of your returned errors are non-exceptional, by all means treat
    them as normal returned variables. See here:
    http://play.golang.org/p/BRLuUGcreI
    And here: http://play.golang.org/p/uRFIBEUjh0

    --
    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/groups/opt_out.
  • Rob Pike at Apr 4, 2013 at 6:31 pm
    Here's what you said in your first mail: "I'm new to Go so let me
    suggest changing it." That is not a winning strategy.

    I suggest instead that you use it more to become familiar with its
    properties, good or bad, before deciding what needs to change.

    -rob

    --
    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/groups/opt_out.
  • Eric Sampson at Apr 4, 2013 at 6:54 pm

    On Thursday, April 4, 2013 1:31:37 PM UTC-5, Rob Pike wrote:
    Here's what you said in your first mail: "I'm new to Go so let me
    suggest changing it." That is not a winning strategy.

    I suggest instead that you use it more to become familiar with its
    properties, good or bad, before deciding what needs to change.

    -rob
    I apologize if that's how it came across Rob - I did not mean to imply that
    anything 'needs' to change. I just wanted to throw some ideas against the
    wall and see what folks thought. If the tone of my correspondence did not
    convey this, then that was my fault.

    Eric

    --
    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/groups/opt_out.
  • Gustavo Niemeyer at Apr 4, 2013 at 6:04 pm

    On Thu, Apr 4, 2013 at 10:44 AM, Eric Sampson wrote:
    func MySqrt(f float64) (float64, error)

    ret1 := MySqrt(-1) :> err1
    Hmm.. we could actually change it so that this works:

    MySqrt(-1) > ret1 2> err1

    ;-)


    gustavo @ http://niemeyer.net

    --
    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/groups/opt_out.
  • Dan Kortschak at Apr 4, 2013 at 8:18 pm
    Extending on that we could easily use the approach to allow testing of the two error case

    MySqrt(-1) > ret1 2> errs 3>&2

    With a few more steps we could build a really flexible scripting tool.
    On 05/04/2013, at 4:34 AM, "Gustavo Niemeyer" wrote:

    Hmm.. we could actually change it so that this works:

    MySqrt(-1) > ret1 2> err1
    --
    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/groups/opt_out.
  • Jesse McNelis at Apr 4, 2013 at 10:30 pm

    On 05/04/2013 12:50 AM, "Eric Sampson" wrote:
    What do you think about the following syntax change, to make the return
    value(s) visually separated from the returned error.

    Error values aren't special enough for that. Other return values can also
    indicate that a function didn't do what you wanted it to. This syntax
    encourages the thinking that errors are all you have to check for.

    --
    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/groups/opt_out.
  • Atomly at Apr 4, 2013 at 11:56 pm
    I hope this doesn't sound mean, but I personally don't really understand
    the purpose of this. The whole point of the Go design, in my opinion, is
    that errors aren't anything special. Any function can return multiple
    values and the if foo := doFoo(); foo != 42 { ... } syntax has absolutely
    nothing to do with errors either.

    If I were going to add anything like this, I'd be fighting for something
    more like exceptions (especially from goroutines.. heh) or something.

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Thu, Apr 4, 2013 at 9:44 AM, Eric Sampson wrote:

    Hi all, please be gentle as I am a brand new golanger :)

    What do you think about the following syntax change, to make the return
    value(s) visually separated from the returned error. I'm not sure what the
    new symbol should be; I used :> below, but =: has a potentially pleasing
    symmetry. I especially like how this proposal looks in the second case,
    since it removes the need to type the error var name twice:


    func MySqrt(f float64) (float64, error)

    ret1 := MySqrt(-1) *:> err1*

    if err1 != nil {

    }

    if ret2 := MySqrt(5) *:> err2 != nil* {

    }






    --
    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/groups/opt_out.

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 4, '13 at 1:49p
activeApr 5, '13 at 3:47a
posts22
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase