slightly different array literal syntax to distinguish from slices

[andrewrk]

Guess what @typeOf(mystery) is:

var hi = "hi";
const mystery = [][]u8{&hi};

It's [1][]u8. It looks like a double slice, but it's actually an array literal with an inferred number of items. It is equivalent to:

var hi = "hi";
const not_a_mystery = [1][]u8{&hi};

This is important because arrays usually can not be used where slices are expected, and it starts to get confusing with const, especially when you consider that there is a missing compile error for this:

const why_isnt_this_an_error = []const []const{"hi"};

The const on the array literal is nonsense and should be a compile error.

It's nice to infer the number of array items, but it shouldn't look like a slice. How about this syntax instead?

var hi = "hi";
const not_a_mystery = [_][]u8{&hi};

[tgschultz]

Or we could use a builtin:

var hi = "hi";
const not_a_mystery = @arrayInit([]u8, &hi); //[1][]u8

[raulgrell]

A few ideas:

var hi = "hi";
const dotdot = [..][]u8{&hi};
const prefixplusplus = ++[][]u8{&hi};
const zero =[0][]u8{&hi};

[hryx]

I'll admit this has bitten me a lot. Love the underscore idea; when I see the _ character I know it means "some value goes here, but I don't really care what it is". And no syntactical conflicts inside the brackets. Builtin is clear, but a bit verbose for such a rudimentary/common operation, in my opinion.

Edit: @raulgrell the .. is nice too, but that might be confusing too because it means the opposite when converting an array into a slice: var slice = array[0..];

[raulgrell]

@hryx Yeah, that's one of it's greatest weaknesses but also its greatest strength:

When slicing, IT occurs on the right of a name, it takes an index and it and refers to a value
When declaring/instantiating, occurs on the left of a name, takes no index, and refers to a type

It's similar to the symmetry with declaring a pointer type with a prefix * and dereferencing it with a postfix .*

[Hejsil]

Related: #568

[andrewrk]

Ah, I was looking for that, thanks @Hejsil. Looks like @thejoshwolfe made an identical proposal to this one in a comment on that issue.

[andrewrk]

I need this for #2602 so I'm going to do this in master branch right now.