FAQ
Just a thought.

I'm thinking that maybe [*]type instead of []type would be more intuitive
as to how slices are references to arrays, having flexible length.

The syntax would be an alternative, not a replacement, not at this time
anyway.

--

Search Discussions

  • Patrick Mylund Nielsen at Jan 7, 2013 at 8:58 pm
    no thanks, it's unnecessary and doesn't really communicate anything more
    than "[]" (which at least to me says no fixed length, especially when you
    know [4] is an array of 4)

    On Mon, Jan 7, 2013 at 1:49 PM, wrote:

    Just a thought.

    I'm thinking that maybe [*]type instead of []type would be more intuitive
    as to how slices are references to arrays, having flexible length.

    The syntax would be an alternative, not a replacement, not at this time
    anyway.

    --

    --
  • Patrick Mylund Nielsen at Jan 7, 2013 at 7:55 pm
    It would also make it require much more effort to tell the difference
    between [*]int, *[2]int, and *[*]int

    On Mon, Jan 7, 2013 at 1:50 PM, Patrick Mylund Nielsen wrote:

    no thanks, it's unnecessary and doesn't really communicate anything more
    than "[]" (which at least to me says no fixed length, especially when you
    know [4] is an array of 4)

    On Mon, Jan 7, 2013 at 1:49 PM, wrote:

    Just a thought.

    I'm thinking that maybe [*]type instead of []type would be more
    intuitive as to how slices are references to arrays, having flexible length.

    The syntax would be an alternative, not a replacement, not at this time
    anyway.

    --

    --
  • Itmitica at Jan 7, 2013 at 7:58 pm
    For me, it would add some consistency and it would help differentiate from
    the empty interface analogy: interface{} vs. []int.

    int [4]int
    *int [*]int

    Though I agree, it's only a small point. Like I said, just a thought.

    --
  • Kevin Gillette at Jan 8, 2013 at 6:11 pm
    I expect it's a pretty quick distinction to learn already (”if there's _anything_ between the brackets, it's an array, otherwise it's a slice”). If a single asterisk between the brackets indicated a slice, you'd get a *lot* of peculiarities:

    *[1]T an array ptr, as it's the case now.
    *[*]T a slice ptr.
    [**]T invalid, but many nuts topics would be started asking why this doesn't declare a slice ptr.
    [*1]T same: why isn't this an arr pointer?

    Since go tutorials tend to leave arrays as an early footnote until slices are rigorously examined, many will indeed be left with the intuition that the pointer syntax goes inside the brackets, and therefore that ”slice” is precisely identical to ”array pointer”, with all the implications therein.

    [?]T as an example, would be an alternative syntax that doesn't conceptually ambiguate pointers and references (which, while closely related, are semantically quite different). Of course, any unambiguous alternatives would likely add another token to the language.

    --
  • Itmitica at Jan 8, 2013 at 6:25 pm
    I never said it's hard to distinguish between arrays and slices.

    My aim was to throw in a recognition sign for the invisible connections
    among slices, pointers and arrays, and to disambiguate from a possible
    empty array/slice interpretation, in regards to the empty interface.

    --
  • Rémy Oudompheng at Jan 8, 2013 at 8:28 pm

    On 2013/1/8 wrote:
    I never said it's hard to distinguish between arrays and slices.

    My aim was to throw in a recognition sign for the invisible connections
    among slices, pointers and arrays, and to disambiguate from a possible empty
    array/slice interpretation, in regards to the empty interface.
    I don't think that was the goal of the notation []T. It looks rather
    simply borrowed from C/C++/Java to look familiar.
    At least it looks familiar to me.

    Rémy.

    --
  • Kevin Gillette at Jan 8, 2013 at 8:50 pm
    Invisible connections? And what do you mean by "empty array/slice
    interpretation", how is it problematic, and how does [*]int solve that?
    Also note that you can't really consider an array to ever be empty, since
    it must always have the exactly the number of elements specified in the
    type.
    On Tuesday, January 8, 2013 11:25:53 AM UTC-7, itmi...@gmail.com wrote:

    I never said it's hard to distinguish between arrays and slices.

    My aim was to throw in a recognition sign for the invisible connections
    among slices, pointers and arrays, and to disambiguate from a possible
    empty array/slice interpretation, in regards to the empty interface.
    --
  • Jan Mercl at Jan 8, 2013 at 8:54 pm

    On Tue, Jan 8, 2013 at 9:49 PM, Kevin Gillette wrote:
    Invisible connections? And what do you mean by "empty array/slice
    interpretation", how is it problematic, and how does [*]int solve that? Also
    note that you can't really consider an array to ever be empty, since it must
    always have the exactly the number of elements specified in the type.
    Is `a` empty or is a non empty? http://play.golang.org/p/T_Zg7p3Xjh

    -j

    --
  • Kevin Gillette at Jan 8, 2013 at 9:53 pm
    I would not call [0]int 'empty', since the concept of 'emptiness' has
    absolutely no semantic value here. Trying to access the 0th element is no
    different then trying to access the 1th element of [1]int (it's not that
    you're trying to access an element of an 'empty array' -- it's that the
    index you're attempting to use is out of bounds). [0]int has consistent
    properties with [1]int or any [n]int, if you consider those properties
    objectively.

    Also, zero-length arrays are so uncommon that imo it's entirely ridiculous
    to modify syntax to 'disambiguate' them, if that's (part of) what this is
    about. It'd be a syntax change to account for less than 10% of array use
    (perhaps less than 1%), and the only think I can think of [0]int being
    really useful for is a synonym for struct{} (for that matter, why not drive
    home the point and use `[0]struct{}` ?)
    On Tuesday, January 8, 2013 1:53:44 PM UTC-7, Jan Mercl wrote:

    On Tue, Jan 8, 2013 at 9:49 PM, Kevin Gillette
    <extempor...@gmail.com <javascript:>> wrote:
    Invisible connections? And what do you mean by "empty array/slice
    interpretation", how is it problematic, and how does [*]int solve that? Also
    note that you can't really consider an array to ever be empty, since it must
    always have the exactly the number of elements specified in the type.
    Is `a` empty or is a non empty? http://play.golang.org/p/T_Zg7p3Xjh

    -j
    --
  • Itmitica at Jan 8, 2013 at 10:02 pm

    On Tuesday, January 8, 2013 11:53:33 PM UTC+2, Kevin Gillette wrote:

    Also, zero-length arrays are so uncommon that imo it's entirely ridiculous
    to modify syntax to 'disambiguate' them, if that's (part of) what this is
    about.
    The fact is, I'm not chasing syntax changes, I'm prospecting syntax
    alternatives.
    So no, this post is no attempt at ridicule, and it turned out to be a
    pretty interesting topic. For me, at least.

    --
  • Itmitica at Jan 8, 2013 at 10:07 pm

    On Wednesday, January 9, 2013 12:03:40 AM UTC+2, kortschak wrote:

    They cannot however be empty.
    nil is a zero value.

    --
  • Dan Kortschak at Jan 8, 2013 at 10:43 pm
    An array cannot take a nil value.
    On 09/01/2013, at 8:37 AM, "itmitica@gmail.com" wrote:

    nil is a zero value.
    --
  • Itmitica at Jan 8, 2013 at 8:58 pm
    I can think of an empty array confusion: http://play.golang.org/p/ueNdnFn-pK

    --
  • Bryanturley at Jan 8, 2013 at 9:28 pm

    On Tuesday, January 8, 2013 2:58:05 PM UTC-6, itmi...@gmail.com wrote:
    I can think of an empty array confusion:
    http://play.golang.org/p/ueNdnFn-pK
    Ehhh... perhaps that may merit some different formatting in Println() but
    that is confusing.

    --
  • Bryanturley at Jan 8, 2013 at 9:57 pm

    On Tuesday, January 8, 2013 3:00:31 PM UTC-6, bryanturley wrote:

    On Tuesday, January 8, 2013 2:58:05 PM UTC-6, itmi...@gmail.com wrote:

    I can think of an empty array confusion:
    http://play.golang.org/p/ueNdnFn-pK
    Ehhh... perhaps that may merit some different formatting in Println() but
    that is confusing.
    Sorry is NOT confusing... heh


    --
  • Itmitica at Jan 8, 2013 at 9:04 pm
    OK then, this is your empty slice: http://play.golang.org/p/WaNuD52rso

    --
  • Rui Maciel at Jan 8, 2013 at 9:13 pm

    On 01/08/2013 08:49 PM, Kevin Gillette wrote:
    Also note that you can't really consider an array to ever be empty, since
    it must always have the exactly the number of elements specified in the
    type.
    Go's language reference states[1] that an array is a numbered sequence
    of elements of a single type. It also states that the length of an
    array is never negative. This means that the length of an array can
    either be a positive integer or zero.

    If the length of an array can be zero then, according to the language
    ref, an array can have zero elements. But this wouldn't make sense.

    So, it appears that either the language ref is a bit off, or in Go an
    array can in fact be empty, which is doubtful.

    Does anyone have any thoughts on this?


    Rui Maciel

    [1] http://golang.org/ref/spec#Array_types

    --
  • Jan Mercl at Jan 8, 2013 at 9:22 pm

    On Tue, Jan 8, 2013 at 10:13 PM, Rui Maciel wrote:
    But this wouldn't make sense.
    You might be completely right on this. But w/o any reasoning it's hard to tell.

    -j

    --
  • Itmitica at Jan 8, 2013 at 9:27 pm

    On Tuesday, January 8, 2013 11:13:27 PM UTC+2, Rui Maciel wrote:

    So, it appears that either the language ref is a bit off, or in Go an
    array can in fact be empty, which is doubtful.
    Yeah, zero is not nil.

    --
  • Minux at Jan 8, 2013 at 9:34 pm

    On Wed, Jan 9, 2013 at 5:13 AM, Rui Maciel wrote:

    If the length of an array can be zero then, according to the language ref,
    an array can have zero elements. But this wouldn't make sense.
    It does make sense, we also have empty struct (struct{}), empty interface
    (interface{}),
    why we can't have empty array ([0]T)?

    in fact, [0]byte is used by cgo as a placeholder for C's void type.

    --
  • Itmitica at Jan 8, 2013 at 9:42 pm

    On Tuesday, January 8, 2013 11:34:12 PM UTC+2, minux wrote:

    It does make sense, we also have empty struct (struct{}), empty interface
    (interface{}),
    why we can't have empty array ([0]T)?
    This brings up an interesting aspect.
    An empty array [0]T is easy to differentiate.
    An empty slice, on the other hand, is not that easily spotted.
    Also, when programmers hear about the possibility of an empty array, []T is
    the first syntax that comes to mind.

    --
  • Kyle Lemons at Jan 8, 2013 at 9:51 pm
    An empty array seems pretty unhelpful. And there's no way to know a slice
    is empty without checking for it programmatically. I could see thinking []
    for empty lists, but not []int.

    On Tue, Jan 8, 2013 at 1:42 PM, wrote:
    On Tuesday, January 8, 2013 11:34:12 PM UTC+2, minux wrote:

    It does make sense, we also have empty struct (struct{}), empty interface
    (interface{}),
    why we can't have empty array ([0]T)?
    This brings up an interesting aspect.
    An empty array [0]T is easy to differentiate.
    An empty slice, on the other hand, is not that easily spotted.
    Also, when programmers hear about the possibility of an empty array, []Tis the first syntax that comes to mind.

    --

    --
  • Itmitica at Jan 8, 2013 at 10:01 pm

    On Tuesday, January 8, 2013 11:50:59 PM UTC+2, Kyle Lemons wrote:
    An empty array seems pretty unhelpful.
    Like any type, an empty array is the zero value for the array type. minux
    already said that.

    --
  • Dan Kortschak at Jan 8, 2013 at 10:03 pm
    The 'array type' is actually a family of n types where n is limited by the size of int. The zero value for any particular one of these is the [n]T where all the available slots are the zero value for T. They cannot however be empty. A black image is not empty and the O matrix is not empty, they are zero. The zero length array must always be in its zero state.
    On 09/01/2013, at 8:26 AM, "itmitica@gmail.com" wrote:

    Like any type, an empty array is the zero value for the array type
    --
  • Kevin Gillette at Jan 8, 2013 at 10:13 pm

    On Tuesday, January 8, 2013 2:56:17 PM UTC-7, itmi...@gmail.com wrote:
    On Tuesday, January 8, 2013 11:50:59 PM UTC+2, Kyle Lemons wrote:

    An empty array seems pretty unhelpful.
    Like any type, an empty array is the zero value for the array type. minux
    already said that.
    That's not accurate at all. There is no singular 'array' type (and
    therefore, there is no 'the' array type). Arrays are a kind of type, or
    family of types, if you prefer, and the size of an array is always part of
    its type. The zero value for [0]int is itself. The zero value for [1]int is
    [1]int{0}. The zero value for [3]int is [3]int{0,0,0}. In other words, the
    zero value for an array type is the value wherein each element is the zero
    value of the element type.

    --
  • Itmitica at Jan 8, 2013 at 10:09 pm

    On Wednesday, January 9, 2013 12:05:53 AM UTC+2, Kevin Gillette wrote:
    That's not accurate at all. The zero value for [1]int is [1]int{0}. The
    zero value for [3]int is [3]int{0,0,0}. In other words, the zero value for
    an array type is the value wherein each element is the zero value of the
    element type.

    No, those are zero *values*. We're talking about the zero *value*.

    --
  • Steven Blenkinsop at Jan 8, 2013 at 10:14 pm
    I can tell you, with absolute certainty, that you aren't saying anything
    meaningful. Please try to describe what you mean to say, and maybe we can
    come up with the correct words for it, which should help clear up the
    myriad of misunderstandings in this thread.

    On Tue, Jan 8, 2013 at 5:09 PM, wrote:
    On Wednesday, January 9, 2013 12:05:53 AM UTC+2, Kevin Gillette wrote:

    That's not accurate at all. The zero value for [1]int is [1]int{0}. The
    zero value for [3]int is [3]int{0,0,0}. In other words, the zero value for
    an array type is the value wherein each element is the zero value of the
    element type.

    No, those are zero *values*. We're talking about the zero *value*.

    --

    --
  • Itmitica at Jan 8, 2013 at 10:48 pm

    On Wednesday, January 9, 2013 12:14:19 AM UTC+2, Steven Blenkinsop wrote:
    Please try to describe what you mean to say, and maybe we can come up with
    the correct words for it, which should help clear up the myriad of
    misunderstandings in this thread.
    This is what I meant to say about zero *value* not zero *values*:
    http://play.golang.org/p/feaHtbDM2Y

    And maybe you should ease up on your tone, will you? This thread I believe
    actually cleared up e few small things. Otherwise, feel free...

    --
  • Itmitica at Jan 8, 2013 at 10:54 pm

    On Wednesday, January 9, 2013 12:43:13 AM UTC+2, kortschak wrote:

    An array cannot take a nil value.
    I didn't imply it would... though, if we're playing this game:

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

    --
  • Itmitica at Jan 8, 2013 at 11:00 pm

    On Wednesday, January 9, 2013 12:56:05 AM UTC+2, kortschak wrote:
    Those are not zero values. They are types with a zero dimension.
    EXACTLY! I said zero *value* not zero *values*!

    --
  • Dan Kortschak at Jan 8, 2013 at 11:17 pm
    No.

    On 09/01/2013, at 9:30 AM, "itmitica@gmail.com " wrote:

    On Wednesday, January 9, 2013 12:56:05 AM UTC+2, kortschak wrote:
    Those are not zero values. They are types with a zero dimension.

    EXACTLY! I said zero value not zero values!

    --


    --
  • Dan Kortschak at Jan 8, 2013 at 11:01 pm
    Those are not zero values. They are types with a zero dimension. The are not empty, though they are in their zero (and only) state.

    On 09/01/2013, at 9:18 AM, "itmitica@gmail.com " wrote:

    This is what I meant to say about zero value not zero values: http://play.golang.org/p/feaHtbDM2Y

    --
  • Kevin Gillette at Jan 8, 2013 at 10:27 pm
    Unless you're talking about an array pointer, or an array of nil-able
    values, 'nil' does not enter the picture. There is no singular 'zero value'
    for all array types, and types in Go are not runtime creatable, therefore
    there's no such thing as a zero value of a set of types. Unless you're
    delving into philosophy, then no, an empty array is not 'the zero value of
    the array type' (again, if 'empty' even means anything semantically, which
    I hold it does not).

    Regarding the earlier 'ridicule', I simply meant that zero-length arrays
    are not common enough to be worth considering when syntax decisions are
    being made; if there's enough argument left over from aspects of the
    language that are regularly being used and are sufficiently confusing to
    enough people, then so be it.

    Rui: it's awkward enough in practice if you try to find reasons to use
    zero-length arrays (aside from being zero-sized types, which are useful,
    for example, to minimally emulate sets using maps), but it is nonetheless
    consistent with the type system theory: there's no real reason not to allow
    them.
    On Tuesday, January 8, 2013 3:09:03 PM UTC-7, itmi...@gmail.com wrote:
    On Wednesday, January 9, 2013 12:05:53 AM UTC+2, Kevin Gillette wrote:

    That's not accurate at all. The zero value for [1]int is [1]int{0}. The
    zero value for [3]int is [3]int{0,0,0}. In other words, the zero value for
    an array type is the value wherein each element is the zero value of the
    element type.

    No, those are zero *values*. We're talking about the zero *value*.
    --
  • Rui Maciel at Jan 9, 2013 at 10:52 am

    On 01/08/2013 10:21 PM, Kevin Gillette wrote:
    Rui: it's awkward enough in practice if you try to find reasons to use
    zero-length arrays (aside from being zero-sized types, which are useful,
    for example, to minimally emulate sets using maps), but it is nonetheless
    consistent with the type system theory: there's no real reason not to allow
    them.
    The bit which I found a bit weird was that I expected variables to
    represent a memory region, which would mean that any variable would have
    a size. As that is not the case with Go then things like zero-size
    variables, as well as zero-length arrays, are, as you've said, consistent.

    So, all is well.


    Rui Maciel

    --
  • Minux at Jan 9, 2013 at 11:34 am

    On Wed, Jan 9, 2013 at 6:52 PM, Rui Maciel wrote:
    On 01/08/2013 10:21 PM, Kevin Gillette wrote:

    Rui: it's awkward enough in practice if you try to find reasons to use
    zero-length arrays (aside from being zero-sized types, which are useful,
    for example, to minimally emulate sets using maps), but it is nonetheless
    consistent with the type system theory: there's no real reason not to
    allow
    them.
    The bit which I found a bit weird was that I expected variables to
    represent a memory region, which would mean that any variable would have a
    size. As that is not the case with Go then things like zero-size
    variables, as well as zero-length arrays, are, as you've said, consistent.
    zero-sized variables in Go does have an associated memory region.
    before Go 1.1, the address of every zero-sized variables are different
    http://play.golang.org/p/uoDkerdeNQ

    after Go 1.1, all will be sharing the same address.

    also, variables don't necessarily need to have associated *memory* region,
    for example,
    an integer or floating point variable could live in a CPU register.

    --
  • Dave Cheney at Jan 9, 2013 at 11:40 am
    And I think this example uses no storage at all,
    http://play.golang.org/p/4r1wklmVUO
    On Wed, Jan 9, 2013 at 10:34 PM, minux wrote:
    On Wed, Jan 9, 2013 at 6:52 PM, Rui Maciel wrote:
    On 01/08/2013 10:21 PM, Kevin Gillette wrote:

    Rui: it's awkward enough in practice if you try to find reasons to use
    zero-length arrays (aside from being zero-sized types, which are useful,
    for example, to minimally emulate sets using maps), but it is nonetheless
    consistent with the type system theory: there's no real reason not to
    allow
    them.

    The bit which I found a bit weird was that I expected variables to
    represent a memory region, which would mean that any variable would have a
    size. As that is not the case with Go then things like zero-size variables,
    as well as zero-length arrays, are, as you've said, consistent.
    zero-sized variables in Go does have an associated memory region.
    before Go 1.1, the address of every zero-sized variables are different
    http://play.golang.org/p/uoDkerdeNQ

    after Go 1.1, all will be sharing the same address.

    also, variables don't necessarily need to have associated *memory* region,
    for example,
    an integer or floating point variable could live in a CPU register.

    --
    --
  • Minux at Jan 9, 2013 at 11:50 am

    On Wed, Jan 9, 2013 at 7:40 PM, Dave Cheney wrote:

    And I think this example uses no storage at all,
    http://play.golang.org/p/4r1wklmVUO
    Right, because the assembly signature for S.hello is:
    TEXT S.hello+0(SB),$0-16
    so, passing a zero-sized variable by value won't use any memory.
    And Go 1.1 introduces the optimization that even passing it by reference
    won't incur additional memory allocations.

    --
  • Kevin Gillette at Jan 9, 2013 at 1:21 pm

    On Wednesday, January 9, 2013 4:34:34 AM UTC-7, minux wrote:

    after Go 1.1, all will be sharing the same address.

    Regardless of type? Will variables of type [0]int and struct{} share the
    same address? It's inconsequential for me, yet intriguing.

    --
  • Rui Maciel at Jan 9, 2013 at 2:22 pm

    On 01/09/2013 01:21 PM, Kevin Gillette wrote:
    Regardless of type? Will variables of type [0]int and struct{} share the
    same address? It's inconsequential for me, yet intriguing.
    It appears so. Taken from Go's specs on size and alignment guarantees[1]:

    <quote>
    A struct or array type has size zero if it contains no fields (or
    elements, respectively) that have a size greater than zero. Two distinct
    zero-size variables may have the same address in memory.
    </quote>


    Rui Maciel

    [1] http://golang.org/ref/spec#Size_and_alignment_guarantees

    --
  • Itmitica at Jan 8, 2013 at 11:17 pm

    On Wednesday, January 9, 2013 12:09:03 AM UTC+2, itmi...@gmail.com wrote:
    On Wednesday, January 9, 2013 12:05:53 AM UTC+2, Kevin Gillette wrote:

    That's not accurate at all. The zero value for [1]int is [1]int{0}. The
    zero value for [3]int is [3]int{0,0,0}. In other words, the zero value for
    an array type is the value wherein each element is the zero value of the
    element type.

    No, those are zero *values*. We're talking about the zero *value*.
    Yes.

    I said: those are zero *values* ([1]int is [1]int{0}, for [3]int is
    [3]int{0,0,0}). We're talking about the zero *value*: [0]int, [0][1]int,
    [0][3]int and so on.*
    *

    --
  • Bryanturley at Jan 8, 2013 at 11:28 pm

    On Tuesday, January 8, 2013 5:17:24 PM UTC-6, itmi...@gmail.com wrote:
    On Wednesday, January 9, 2013 12:09:03 AM UTC+2, itmi...@gmail.com wrote:
    On Wednesday, January 9, 2013 12:05:53 AM UTC+2, Kevin Gillette wrote:

    That's not accurate at all. The zero value for [1]int is [1]int{0}. The
    zero value for [3]int is [3]int{0,0,0}. In other words, the zero value for
    an array type is the value wherein each element is the zero value of the
    element type.

    No, those are zero *values*. We're talking about the zero *value*.
    Yes.

    I said: those are zero *values* ([1]int is [1]int{0}, for [3]int is
    [3]int{0,0,0}). We're talking about the zero *value*: [0]int, [0][1]int,
    [0][3]int and so on.*
    *

    x := int(0)

    --
  • Itmitica at Jan 8, 2013 at 11:23 pm

    On Wednesday, January 9, 2013 1:20:04 AM UTC+2, bryanturley wrote:

    x := int(0)
    Exactly, that simple!

    --
  • Itmitica at Jan 8, 2013 at 11:49 pm
    OK Dan, can I tell you you're nitpick-ngly "missing" the point :)
    --
  • Itmitica at Jan 8, 2013 at 11:52 pm

    On Wednesday, January 9, 2013 1:43:39 AM UTC+2, kortschak wrote:
    [0]int is not a value. It is a type. The zero value of that type would
    be [0]int{}.
    And no.

    The zero value would be []: http://play.golang.org/p/32hDAJ5804

    --
  • Dan Kortschak at Jan 8, 2013 at 11:54 pm
    ... or not: http://play.golang.org/p/ChLwbJVala

    Notice how you assigned that value.

    On 09/01/2013, at 10:22 AM, "itmitica@gmail.com " wrote:

    On Wednesday, January 9, 2013 1:43:39 AM UTC+2, kortschak wrote:
    [0]int is not a value. It is a type. The zero value of that type would be [0]int{}.

    And no.

    The zero value would be []: http://play.golang.org/p/32hDAJ5804

    --


    --
  • Itmitica at Jan 8, 2013 at 11:58 pm

    On Wednesday, January 9, 2013 1:52:34 AM UTC+2, kortschak wrote:
    Try making that point more clearly then.
    Bryan did it for me.

    What 0 is for int, [0]T is for array. The zero value.

    0*1 = 0
    0*2 = 0

    [0][1]T = [0]T
    [0][2]T = [0]T

    --
  • Steven Blenkinsop at Jan 9, 2013 at 12:20 am

    On Tue, Jan 8, 2013 at 6:58 PM, wrote:
    On Wednesday, January 9, 2013 1:52:34 AM UTC+2, kortschak wrote:

    Try making that point more clearly then.
    Bryan did it for me.

    What 0 is for int, [0]T is for array. The zero value.

    0*1 = 0
    0*2 = 0

    [0][1]T = [0]T
    [0][2]T = [0]T
    http://play.golang.org/p/pfbIWOCiMj

    Also, it only looks like this because type information is hidden. In Go,
    the values are different because their types are different. There exists no
    idea of equality between two values of different types:
    http://play.golang.org/p/N3MdZtOVFu

    --
  • Itmitica at Jan 9, 2013 at 12:28 am

    On Wednesday, January 9, 2013 2:19:50 AM UTC+2, Steven Blenkinsop wrote:

    http://play.golang.org/p/pfbIWOCiMj
    I'd be lying if I'd be saying I didn't expect this. Obviously, you know,
    and I know, and everyone knows what I meant. I see no point to that
    [10][0]int...

    Also, it only looks like this because type information is hidden. In Go,
    the values are different because their types are different. There exists no
    idea of equality between two values of different types:
    http://play.golang.org/p/N3MdZtOVFu
    It doesn't prove anything: http://play.golang.org/p/POQB5XH2YN


    --
  • Dan Kortschak at Jan 9, 2013 at 12:31 am
    That can be spelled longer

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

    There the zero length arrays are explicitly stated. However try not including any braces.

    On 09/01/2013, at 10:58 AM, "itmitica@gmail.com " wrote:

    On Wednesday, January 9, 2013 2:19:50 AM UTC+2, Steven Blenkinsop wrote:

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

    I'd be lying if I'd be saying I didn't expect this. Obviously, you know, and I know, and everyone knows what I meant. I see no point to that [10][0]int...

    Also, it only looks like this because type information is hidden. In Go, the values are different because their types are different. There exists no idea of equality between two values of different types:
    http://play.golang.org/p/N3MdZtOVFu

    It doesn't prove anything: http://play.golang.org/p/POQB5XH2YN


    --


    --
  • Itmitica at Jan 9, 2013 at 12:35 am

    On Wednesday, January 9, 2013 2:28:39 AM UTC+2, kortschak wrote:
    Again, array is not a type, it is a collection of types.
    No, array is a type name.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 7, '13 at 7:49p
activeJan 9, '13 at 2:22p
posts83
users13
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase