[go-nuts] Alternative syntax for slice type

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)

It would also make it require much more effort to tell the difference
between [*]int, *[2]int, and *[*]int

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.

--

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.

--

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.

--

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

--

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{}` ?)

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.

--

nil is a zero value.

--

An array cannot take a nil value.

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


--

OK then, this is your empty slice: http://play.golang.org/p/WaNuD52rso

--

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

--

You might be completely right on this. But w/o any reasoning it's hard to tell.

-j

--

Yeah, zero is not nil.

--

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.

--

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.

--

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.

Like any type, an empty array is the zero value for the array type. minux
already said that.

--

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.

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.

--

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

--

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.

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

--

I didn't imply it would... though, if we're playing this game:

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

--

EXACTLY! I said zero *value* not zero *values*!

--

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!

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

--

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.

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

--

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.

--

And I think this example uses no storage at all,
http://play.golang.org/p/4r1wklmVUO

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.

--

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

--

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)

--

Exactly, that simple!

--

OK Dan, can I tell you you're nitpick-ngly "missing" the point :)
--

And no.

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

--

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

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

--

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

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


--

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

No, array is a type name.

--