FAQ
Hi all.

This breaks:

http://play.golang.org/p/dQdpAqJ74q

I assume, internally, for the same reason that this breaks:

http://play.golang.org/p/fp_YQGJZTL

Which is documented even in the FAQ [1].

But the spec [2] says this:
If f is variadic with a final parameter p of type ...T, then within f the type of p is equivalent to type []T. [...] Otherwise, the value passed is a new slice of type []T with a new underlying array whose successive elements are the actual arguments, which all must be assignable to T.
"Which all must be assignable to T". And, also by the spec [3]:
A value x is assignable to a variable of type T ("x is assignable to T") in any of these cases: [...] T is an interface type and x implements T.
In this case, T is interface{}, and x is string, and string implements interface{}. Thus, all actual arguments to

So, for what I understand, this is a bug either in the or in the spec. What do you think?

[1]: http://golang.org/doc/faq#convert_slice_of_interface
[2]: http://golang.org/ref/spec#Passing_arguments_to_..._parameters
[3]: http://golang.org/ref/spec#Assignability

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

  • Dustin at Jul 9, 2015 at 5:02 pm
    From my reading of the spec, it says that the last parameter is "equivalent
    to type []T" which in go []interface{} != []string. The assignable part
    only comes into play if you use a list of args instead of "..." notation
    that's why it says "Otherwise --- successive elements are the actual
    arguments".
    On Thursday, July 9, 2015 at 9:48:41 AM UTC-7, Toni Cárdenas wrote:

    Hi all.

    This breaks:

    http://play.golang.org/p/dQdpAqJ74q

    I assume, internally, for the same reason that this breaks:

    http://play.golang.org/p/fp_YQGJZTL

    Which is documented even in the FAQ [1].

    But the spec [2] says this:

    If f is variadic with a final parameter p of type ...T, then within f the
    type of p is equivalent to type []T. [...] Otherwise, the value passed is a
    new slice of type []T with a new underlying array whose successive elements
    are the actual arguments, which all must be assignable to T.


    "Which all must be assignable to T". And, also by the spec [3]:

    A value x is assignable to a variable of type T ("x is assignable to T")
    in any of these cases: [...] T is an interface type and x implements T.

    In this case, T is interface{}, and x is string, and string implements
    interface{}. Thus, all actual arguments to

    So, for what I understand, this is a bug either in the or in the spec.
    What do you think?

    [1]: http://golang.org/doc/faq#convert_slice_of_interface
    [2]: http://golang.org/ref/spec#Passing_arguments_to_..._parameters
    [3]: http://golang.org/ref/spec#Assignability
    --
    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.
  • Dan Kortschak at Jul 9, 2015 at 8:07 pm
    I don't think the text actually says that, though it is undoubtedly intended that a user cannot use a variadic function to perform slice type conversion that would otherwise be illegal.

    The paragraph only talks about T, not the slice of T except for the how the parameter is "equivalent" which is pretty loose and given that there is more being discussed open to interpretation. The "otherwise" follows immediately on from a description of the zero length case, so is describing any case where there is a non zero length list (either p1, p2, ... pn, or p...) so I don't think the explanation below holds.

    I would open an issue against the spec.
    On 10/07/2015, at 2:33 AM, "Dustin" wrote:

    The assignable part only comes into play if you use a list of args instead of "..." notation that's why it says "Otherwise --- successive elements are the actual arguments".
    --
    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.
  • Dustin at Jul 9, 2015 at 8:27 pm
    I think these two points in the spec cover it pretty well:

    "the value passed is a new slice of type []T with a new underlying array
    whose *successive elements are* *the actual arguments*, which all must be
    assignable <http://golang.org/ref/spec#Assignability> to T"
    "If the *final argument* *is* *assignable to a slice type **[]T*, it may be
    passed unchanged as the value for a ...T parameter if the argument is
    followed by ...."

    I think this is pretty clear that you either pass args which are assignable
    to T, or something assignable to []T followed by ... (note []S is not
    assignable to []T even if S is assignable to T)

    --
    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.
  • Dan Kortschak at Jul 9, 2015 at 9:07 pm
    Yes, in my pre-coffee state, I missed that - the sentence that answers this completely.

    On 10/07/2015, at 5:57 AM, "Dustin" wrote:

    "If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by ...."

    --
    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.
  • Adam willis at Jul 9, 2015 at 9:45 pm
    with small adjustments those examples can run. But maybe im not
    understanding the question correctly.

    http://play.golang.org/p/NgiMJo6yKe
    http://play.golang.org/p/dsngEBkin6


    I think your issue arises from the work that happens within fmt.Println. I
    recall seeing a thread about how fmt.Println works that could possibly
    relate to this - but I could be mistaken.

    --
    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
postedJul 9, '15 at 4:48p
activeJul 9, '15 at 9:45p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase