Reevaluate syntax for fixed-length vector types

[brson]

let foo: [int, .. N]? As a type name it's pretty unsightly. Some would like to go back to the drawing board here.

[brson]

Nominating.

[kud1ing]

Maybe something like let foo: [int]{N}: first the list declaration [int] and than an additional length constraint in some form.

[jdm]

Perhaps let foo: [int:N]?

[huonw]

Do we want this to match the repeat syntax? I could imagine both

let x = [10u]{128};
let x = [10u: 128];

have problems; the first one would make something like let x = [1 + 2 + 3 + ... + n]{100}; require arbitrary look-ahead to work out if it is a vector of length 1 or a repeat expression (edit: although I guess we already have this with [1 + 2 + ... + n, .. 100]; but this syntax makes the error for forgetting the ; in let x = [0]; { /* scope */ } weird, and it also makes if x == [0] { ... } impossible). The last one conflicts with the proposed use of : for type-ascription.

[nikomatsakis]

the first one would make something like let x = [1 + 2 + 3 + ... + n]{100}; require arbitrary look-ahead to work out if it is a vector
of length 1 or a repeat expression.

Not to endorse [10u]{128} as a possible syntax, but it does not
require arbitrary lookahead because it is not necessary to distinguish
between vectors of length 1 and repeat expressions until the end of
the expression (this is distinct from, say, foo<T>, where we would
need to know before we parse T whether it is an expression or a
type).

[catamorphism]

1.0, high (not committing to change it yet, just to discuss it)

[bstrie]

IMO, Rust got it right by putting the inner type of a vector inside rather than before the braces (i.e. [int] rather than int[]). I'm eager in preserving that property, even if it does make the fixed-length syntax a little more unsightly.

Personally I don't have an issue with [T, ..n] on its own. However, now that we've introduced the three-dot ellipsis into the parser (as per #10064), I do worry a little that we'll be tempted to use it elsewhere, and without a clear and memorable meaning for these symbols we risk people never being able to remember when to use .. vs when to use .... So then, is .. our "repeat" operator? And is this consistent with all the contexts in which it is used?

As for proposals, I really want to avoid overloading : even more (especially if we plan on going through with pcwalton's generalized type ascription syntax one day). Maybe we could do something with #? [int#5], perhaps. Though I don't think that really looks any better than the current syntax.

[Kimundi]

I think keeping [T, ..N] is fine as a mirror to the construction expression, and also on it's own: "A vector of T, repeated N times"

[nikomatsakis]

I am basically happy with the current syntax, except that I think I'd prefer .... Or possibly just prefer that we use either .. or ... but not both. (cc #10064) Compare: [int, ...32] vs [int, ..32]. Three dots somehow looks more intensional to me, whereas .. looks like it could have been a typo. But is this vague reasoning enough to cause us to modify existing code? Probably not. I should have spoken up earlier I guess!

[brendanzab]

@nikomatsakis ... takes up a great deal of room. The terseness of .. is nice.

But yeah, I don't have any issues with the current syntax. Makes me smile actually (yes, very good reasoning there). We used to have [T * N] which probably made more sense, but it was confusing when combined with constexprs.

[brson]

It sounds like there's not a lot of momentum to change this, and there aren't a lot of good options. Wontfix?

[brson]

Note that with DST we're probably going to need a fixed length string syntax, so this may come up again.

[brson]

Nominating to close, assuming we're ok with reusing this syntax for fixed-length strings if we need to.

[Kimundi]

I think long-term str could move to the library with DST, so even if we need a special syntax at the beginning, it would likely be temporary anyway.

[brson]

Wontfix.