FAQ
I've been using Go since 1.0 and I love basically everything about it, the
error handling, the interfaces, tooling etc etc.

I write a lot of table driven tests and often have something that looks
like this: http://play.golang.org/p/xFUjIk_nlD
And I was surprised to see that I was required to do []string when
providing the literal for the string array, I assumed Go would figure out
what type I wanted to make at least because that was the type expected by
the struct.

Then I thought why can't Go inference these types automatically anyways,
even without the struct definition from the example above. Is it a problem
to assume map[string]int if that's what it sees? Or []int?

Some examples to solidify the question:

// Could this type inference to map[string]int without having to specify it?
myFunc({"string": 5})
// Could this just "be" a []float64?
var x = {3.4, 6.7}

Just wanted to generate some discussion on this. Cheers.

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

  • Cenk Altı at Oct 25, 2014 at 7:00 pm
    What will the following be? []int or []int32 or []int64 or []byte

    var x = {1, 2, 3}
    On Saturday, October 25, 2014 9:38:49 PM UTC+3, bit...@gmail.com wrote:

    I've been using Go since 1.0 and I love basically everything about it, the
    error handling, the interfaces, tooling etc etc.

    I write a lot of table driven tests and often have something that looks
    like this: http://play.golang.org/p/xFUjIk_nlD
    And I was surprised to see that I was required to do []string when
    providing the literal for the string array, I assumed Go would figure out
    what type I wanted to make at least because that was the type expected by
    the struct.

    Then I thought why can't Go inference these types automatically anyways,
    even without the struct definition from the example above. Is it a problem
    to assume map[string]int if that's what it sees? Or []int?

    Some examples to solidify the question:

    // Could this type inference to map[string]int without having to specify
    it?
    myFunc({"string": 5})
    // Could this just "be" a []float64?
    var x = {3.4, 6.7}

    Just wanted to generate some discussion on this. Cheers.
    --
    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.
  • Bits128 at Oct 25, 2014 at 7:16 pm
    Fairly obvious that would default the same way in which var x = 5 defaults
    now? If you want something specific, use the specific syntax in both cases.

    --
    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.
  • Jesper Louis Andersen at Oct 25, 2014 at 9:19 pm

    On Sat, Oct 25, 2014 at 8:59 PM, Cenk Altı wrote:

    What will the following be? []int or []int32 or []int64 or []byte

    In a type inference algorithm, usually the most general type possible,
    given other constraints in the program. That is, if values gets used as
    []byte, then it is []byte, but note that it is so statically, in the sense
    that it can't be both []int64 and []int32 in the same body. Once you "latch
    onto" a given type, then that type it must be for the remainder of that
    scope. Hindley-Milner type inference is the most common model. One way of
    seeing this is that you form a set of type constraints "T1 == T2" and then
    you use a constraint solver to solve the equations into a solution. For
    instance:

    A == B (1)
    B == int32 (2)

    solves because 2 can be substituted into 1 to figure out what A is.

    The key is that the type of a given value is given by its context as much
    as it is given by itself.

    If you want to pursue this, you must also look into parametric polymorphism
    and type classes. Those two features are what provides "generics" in
    Haskell.


    --
    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.
  • Tahir at Oct 25, 2014 at 11:31 pm
    It has maintenance costs to add such features. So I fail to see how
    valuable it would be to add this one. Also, I would leave brackets for
    structs. Imagine your code with brackets absolutely everywhere.. yuck :o)

    I think having only one way to define things, in an explicit fashion as
    much as possible, is always better for code readability.

    That's just my little opinion.

    Btw, in your playground example, you use an anonymous struct. Do you really
    have to usually ? Perhaps, you would win at being more explicit if possible.
    On Saturday, October 25, 2014 7:38:49 PM UTC+1, bit...@gmail.com wrote:

    I've been using Go since 1.0 and I love basically everything about it, the
    error handling, the interfaces, tooling etc etc.

    I write a lot of table driven tests and often have something that looks
    like this: http://play.golang.org/p/xFUjIk_nlD
    And I was surprised to see that I was required to do []string when
    providing the literal for the string array, I assumed Go would figure out
    what type I wanted to make at least because that was the type expected by
    the struct.

    Then I thought why can't Go inference these types automatically anyways,
    even without the struct definition from the example above. Is it a problem
    to assume map[string]int if that's what it sees? Or []int?

    Some examples to solidify the question:

    // Could this type inference to map[string]int without having to specify
    it?
    myFunc({"string": 5})
    // Could this just "be" a []float64?
    var x = {3.4, 6.7}

    Just wanted to generate some discussion on this. Cheers.
    --
    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 25, 2014 at 11:39 pm
    Oh wait, I see what you mean and I had wondered the same thing when I
    started.
    But what you really want instead of var x = {3.4, 6.7} is probably var x =
    3.4 , 6.7 ( I mean losing the brackets too which are resulting from having
    the type annotation).
    It could probably be doable but I think readability would be worse because
    of the lack of delimiters.

    But it will prolly make compilation slower and does not add too much.
    On Saturday, October 25, 2014 7:38:49 PM UTC+1, bit...@gmail.com wrote:

    I've been using Go since 1.0 and I love basically everything about it, the
    error handling, the interfaces, tooling etc etc.

    I write a lot of table driven tests and often have something that looks
    like this: http://play.golang.org/p/xFUjIk_nlD
    And I was surprised to see that I was required to do []string when
    providing the literal for the string array, I assumed Go would figure out
    what type I wanted to make at least because that was the type expected by
    the struct.

    Then I thought why can't Go inference these types automatically anyways,
    even without the struct definition from the example above. Is it a problem
    to assume map[string]int if that's what it sees? Or []int?

    Some examples to solidify the question:

    // Could this type inference to map[string]int without having to specify
    it?
    myFunc({"string": 5})
    // Could this just "be" a []float64?
    var x = {3.4, 6.7}

    Just wanted to generate some discussion on this. Cheers.
    --
    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.
  • Bits128 at Oct 26, 2014 at 12:05 am
    Tahir, I actually don't believe you've grasped what I'm looking for.

    First off, if I want to make an array of integers currently I have to do:
    var x = []int{5, 6}
    What I'm asking about would allow:
    var x = {5, 6}
    This doesn't add more brackets, in fact it removes some square ones.

    I'm not sure what you meant by var x = 3.4, 6.7 this is not something I'm
    proposing and is very confusing as it's already part of this syntax: var
    x, y = 3.4, 6.7

    You noted being as explicit as possible to increase readability but I feel
    like these two constructs are not different enough to have explicitness be
    a counter-argument:
    var x = 5
    var x = {5, 6}

    This issue isn't about discussing my use of anonymous structs for
    table-driven-tests, this is something used quite a bit in Go even in the
    standard library and I'm pretty happy with it. Using an explicit struct
    type doesn't change the issue since I still need the []string{} to
    instantiate the string array literal.
    On Saturday, October 25, 2014 4:39:45 PM UTC-7, Tahir wrote:

    Oh wait, I see what you mean and I had wondered the same thing when I
    started.
    But what you really want instead of var x = {3.4, 6.7} is probably var x =
    3.4 , 6.7 ( I mean losing the brackets too which are resulting from having
    the type annotation).
    It could probably be doable but I think readability would be worse because
    of the lack of delimiters.

    But it will prolly make compilation slower and does not add too much.
    On Saturday, October 25, 2014 7:38:49 PM UTC+1, bit...@gmail.com wrote:

    I've been using Go since 1.0 and I love basically everything about it,
    the error handling, the interfaces, tooling etc etc.

    I write a lot of table driven tests and often have something that looks
    like this: http://play.golang.org/p/xFUjIk_nlD
    And I was surprised to see that I was required to do []string when
    providing the literal for the string array, I assumed Go would figure out
    what type I wanted to make at least because that was the type expected by
    the struct.

    Then I thought why can't Go inference these types automatically anyways,
    even without the struct definition from the example above. Is it a problem
    to assume map[string]int if that's what it sees? Or []int?

    Some examples to solidify the question:

    // Could this type inference to map[string]int without having to specify
    it?
    myFunc({"string": 5})
    // Could this just "be" a []float64?
    var x = {3.4, 6.7}

    Just wanted to generate some discussion on this. Cheers.
    --
    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 26, 2014 at 12:23 am
    I thought that you wanted to get rid of the type annotation completely
    (which would be real type inference). Doing so would mean removing the
    curly brackets altogether.

    What you propose is having more inference added to the declaration of
    slices and arrays.

    I still think that if we have to keep the braces, then let's keep the whole
    annotation. It's less work for the compiler and the person writing it.

    And for the cases where you are not dealing with builtin types, it's
    clearer.
    On Sunday, October 26, 2014 1:05:13 AM UTC+1, bit...@gmail.com wrote:

    Tahir, I actually don't believe you've grasped what I'm looking for.

    First off, if I want to make an array of integers currently I have to do:
    var x = []int{5, 6}
    What I'm asking about would allow:
    var x = {5, 6}
    This doesn't add more brackets, in fact it removes some square ones.

    I'm not sure what you meant by var x = 3.4, 6.7 this is not something I'm
    proposing and is very confusing as it's already part of this syntax: var
    x, y = 3.4, 6.7

    You noted being as explicit as possible to increase readability but I feel
    like these two constructs are not different enough to have explicitness be
    a counter-argument:
    var x = 5
    var x = {5, 6}

    This issue isn't about discussing my use of anonymous structs for
    table-driven-tests, this is something used quite a bit in Go even in the
    standard library and I'm pretty happy with it. Using an explicit struct
    type doesn't change the issue since I still need the []string{} to
    instantiate the string array literal.
    On Saturday, October 25, 2014 4:39:45 PM UTC-7, Tahir wrote:

    Oh wait, I see what you mean and I had wondered the same thing when I
    started.
    But what you really want instead of var x = {3.4, 6.7} is probably var x
    = 3.4 , 6.7 ( I mean losing the brackets too which are resulting from
    having the type annotation).
    It could probably be doable but I think readability would be worse
    because of the lack of delimiters.

    But it will prolly make compilation slower and does not add too much.
    On Saturday, October 25, 2014 7:38:49 PM UTC+1, bit...@gmail.com wrote:

    I've been using Go since 1.0 and I love basically everything about it,
    the error handling, the interfaces, tooling etc etc.

    I write a lot of table driven tests and often have something that looks
    like this: http://play.golang.org/p/xFUjIk_nlD
    And I was surprised to see that I was required to do []string when
    providing the literal for the string array, I assumed Go would figure out
    what type I wanted to make at least because that was the type expected by
    the struct.

    Then I thought why can't Go inference these types automatically anyways,
    even without the struct definition from the example above. Is it a problem
    to assume map[string]int if that's what it sees? Or []int?

    Some examples to solidify the question:

    // Could this type inference to map[string]int without having to specify
    it?
    myFunc({"string": 5})
    // Could this just "be" a []float64?
    var x = {3.4, 6.7}

    Just wanted to generate some discussion on this. Cheers.
    --
    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.
  • Rob Pike at Oct 26, 2014 at 12:43 am
    It would need more rules to work, making the language more complicated. You
    are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Bits128 at Oct 26, 2014 at 1:27 am
    Well no point in debating or trying to defend after the veto from Rob,
    despite flaws in the counter-argument.
    I'll try not to "lower the bar" anymore with discussion.

    Sorry I brought it up.
    On Saturday, October 25, 2014 5:43:58 PM UTC-7, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Justin Israel at Oct 26, 2014 at 1:56 am
    I don't think it was a veto. It sounded to me more like a observation, that
    the proposal is flawed and doesn't explain the ambiguities that it
    introduces.
    On Sun, Oct 26, 2014 at 2:27 PM, wrote:

    Well no point in debating or trying to defend after the veto from Rob,
    despite flaws in the counter-argument.
    I'll try not to "lower the bar" anymore with discussion.

    Sorry I brought it up.
    On Saturday, October 25, 2014 5:43:58 PM UTC-7, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/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.
  • Akwillis at Oct 31, 2014 at 1:38 am
    Ok, but why the keyword 'type'. Just seems like lazy parsing techniques at
    the expense of more keystrokes. Ironic considering the frugal attempts to
    limit keystrokes elsewhere in the syntax.
    On Saturday, October 25, 2014 8:43:58 PM UTC-4, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Andrewchamberss at Oct 31, 2014 at 1:50 am
    You say lazy parsing techniques", I say "avoid the monstrosity that is
    parsing C++ correctly". Seriously, Its not lazy to make things less
    ambiguous. Go doesn't require a team of well funded experts just to parse
    the damn thing.
    On Friday, October 31, 2014 2:38:53 PM UTC+13, akwillis wrote:

    Ok, but why the keyword 'type'. Just seems like lazy parsing techniques at
    the expense of more keystrokes. Ironic considering the frugal attempts to
    limit keystrokes elsewhere in the syntax.
    On Saturday, October 25, 2014 8:43:58 PM UTC-4, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Andrewchamberss at Oct 31, 2014 at 1:58 am
    I'd also like to point out that the var and type keywords are excellent
    things when it comes to error recovery when developing things like IDE
    error underlining. You have a clear place to resume parsing where a new
    statement begins.
    On Friday, October 31, 2014 2:38:53 PM UTC+13, akwillis wrote:

    Ok, but why the keyword 'type'. Just seems like lazy parsing techniques at
    the expense of more keystrokes. Ironic considering the frugal attempts to
    limit keystrokes elsewhere in the syntax.
    On Saturday, October 25, 2014 8:43:58 PM UTC-4, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Tahir at Oct 31, 2014 at 3:15 am
    So that you are prepared for the day when types become first class objects
    perhaps.
    On Friday, October 31, 2014 1:38:53 AM UTC, akwillis wrote:

    Ok, but why the keyword 'type'. Just seems like lazy parsing techniques at
    the expense of more keystrokes. Ironic considering the frugal attempts to
    limit keystrokes elsewhere in the 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/d/optout.
  • Drj at Oct 31, 2014 at 9:43 am
    If the language is easy to parse, tooling becomes simpler. Go was designed
    with that in mind. [0]
    The number of awesome tools shows how powerful this approach is.

    -david

    [0] http://talks.golang.org/2012/splash.article#TOC_17.
    On Friday, October 31, 2014 2:38:53 AM UTC+1, akwillis wrote:

    Ok, but why the keyword 'type'. Just seems like lazy parsing techniques at
    the expense of more keystrokes. Ironic considering the frugal attempts to
    limit keystrokes elsewhere in the syntax.
    On Saturday, October 25, 2014 8:43:58 PM UTC-4, Rob 'Commander' Pike wrote:

    It would need more rules to work, making the language more complicated.
    You are using a trivial example that avoids all the hard parts.

    var x = {1, 2.3}
    var x = {1,1e2}
    var x = {i, 1}

    and so on. Besides, what is that? An array? A slice? A struct? Absent the
    type, it could be any of those. If you make a choice, you penalize the
    others.

    The type is there for a reason. It makes things clear.

    This proposal is nowhere near the ever-raising bar for adding features to
    Go 1.

    -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/d/optout.
  • Bits128 at Oct 31, 2014 at 5:03 pm
    People keep saying that this proposal has ambiguities and that it's so much
    harder to parse but I don't understand why?

    Maybe someone could point out the flaws with it. In a more concrete way
    rather than just saying the words. Keeping in mind that this syntax
    can't be an array or a struct like was suggested because in Go an array
    must have a length declared, and fairly obviously there's no default struct
    that we could default to so structs must have the type name. It has two
    possibilities only: A map or a slice. And it seems straightforward enough
    to differentiate from each other; if you see the : token in there, it's a
    map.

    As for the types, I find it hard to believe that it's much different than
    the base case for type inference (var). I mean currently the compiler
    already checks types
    versus the other elements in slice literals, for example []int{5, 7.5}
    causes an error. So it's already evaluating each element for it's types.
    What's the difficulty
    in assuming the first element defines the type of the slice or map literal
    and then continue on as if that type was specified explicitly? With some
    doing might even be able
    to use the same code paths after discovering the type.

    Here are some more cases:
    x := {4, 5.7} // Constant value 5.7 truncated to integer, doesn't compile
    x := {5.7, 4} // This is okay, since the type of the slice becomes float64
    and 4 can be converted.

    x := {"map": 5, true: 7.4} // Cannot use true (type bool) as type string in
    slice literal, Constant value 7.4 truncated to integer

    i := 5
    x := {i} // This is the most ambiguous case visually, but it's no more
    ambiguous than the following:
    x := i
    // Someone might decide it's better to do the following for clarity and
    this proposal doesn't stop this:
    x := []int{i}
    var x int = i


    I like how simple go is, and as for how type is determined it seems simple
    and an easy implementation to say: "The first element defines the type of a
    slice or map where the type is not explicitly defined."

    I don't see how it's not reasonable to make a simple adjustment in our
    minds to see these three things as more of the same:
    var x = 5 // We know this is int
    var y = {5, x} // Not hard to tell this is []int
    var z = {"key": y} // Type is just as clear as a := y which exists in Go
    today


    So with that, maybe someone can point out some actual ambiguities or
    problems it introduces in the parser/grammar that make this a bad proposal.
    So far I've seen
    nothing that actually shows why this can't be a part of the language. A
    good example might be: perhaps it's impossible to differentiate from
    creating an additional scope and this form of literal since they both use
    {} (although the context in which these are allowed should hopefully
    eliminate that possibility).
    Maybe the explanation is that it would be fine for the compiler because
    it's smart, but it messes up the grammar for dumber parsers and makes it
    ambiguous.

    I'm clearly no expert on this stuff, so all I want is for one to come along
    and clearly explain why it doesn't work the way I think it does instead of
    just saying it doesn't.
    On Friday, October 31, 2014 2:43:07 AM UTC-7, drj wrote:

    If the language is easy to parse, tooling becomes simpler. Go was designed
    with that in mind. [0]
    The number of awesome tools shows how powerful this approach is.

    -david

    [0] http://talks.golang.org/2012/splash.article#TOC_17.
    --
    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 31, 2014 at 5:18 pm

    On Fri, Oct 31, 2014 at 10:03 AM, wrote:
    People keep saying that this proposal has ambiguities and that it's so much
    harder to parse but I don't understand why?
    Go doesn't have any special cases of expressions that can only appear
    on the right hand side of :=. You need to consider this new
    expression syntax in all places where it might appear, or you need to
    make a good justification for why this can only appear on the right
    hand side of :=. If you take the latter course, you need to consider
    nesting, function calls within the expression, etc.

    If you accept that this new expression syntax can appear anywhere, I
    suspect that there are multiple ambiguities. For example

         for { a, b }[0] { f() }

    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.
  • Bits128 at Oct 31, 2014 at 6:00 pm
    Thanks for the good counter-example Ian. Cases like you've mentioned using
    for or if could be problematic.

    if {5, 6}[0] == 5 {
    }
    if x := {5, 6}; len(x) > 1 {
    }

    A parser would be still be deciding by the end of the } if it saw anything
    but values and map/slice literal tokens
    or if it's seeing valid Go code. But that may already be too late since by
    then we would already like to be parsing
    the code that's inside the body of whatever we're dealing with.

    That's enough for me to stop pushing since it'd introduce some form of
    backtracking into the parser which I recall
    hearing is not something that's in Go's compiler thanks to { before \n
    currently and like others I don't want to see it
    make an appearance. The only other option we'd have is to go for a
    different delimiting syntax, and the entire reason
    I thought this was okay was because it used the same delimiters and just
    dropped the type so it's just not worth it.
    On Friday, October 31, 2014 10:18:43 AM UTC-7, Ian Lance Taylor wrote:

    On Fri, Oct 31, 2014 at 10:03 AM, <bit...@gmail.com <javascript:>>
    wrote:
    People keep saying that this proposal has ambiguities and that it's so much
    harder to parse but I don't understand why?
    Go doesn't have any special cases of expressions that can only appear
    on the right hand side of :=. You need to consider this new
    expression syntax in all places where it might appear, or you need to
    make a good justification for why this can only appear on the right
    hand side of :=. If you take the latter course, you need to consider
    nesting, function calls within the expression, etc.

    If you accept that this new expression syntax can appear anywhere, I
    suspect that there are multiple ambiguities. For example

    for { a, b }[0] { f() }

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 25, '14 at 6:38p
activeOct 31, '14 at 6:00p
posts19
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase