Should we remove int[$] before 2.067?

[Andrei Alexandrescu via Digitalmars-d]

On 1/30/15 10:40 AM, Foo wrote:
> On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
>> On 30/01/2015 16:53, Nick Treleaven wrote:
>>> This version of staticArray allows the user to (optionally) specify the
>>> element type.
>>
>> Actually, I'm having trouble implementing staticArray like that,
>> perhaps there are compiler issues causing problems. Using this:
>>
>> T[len] staticArray(T, size_t len)(T[len] items)
>> {
>>     return items;
>> }
>>
>> you would need to call it: staticArray([a, b, c]). UFCS doesn't seem
>> to work, and I can't get the immutable or function array example to
>> compile either (with the extra [brackets])...
>
> That is such a ugly call. Consider this:
>
> ----
> @nogc
> @safe
> T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
>      return values;
> }
>
> void main() {
>      pragma(msg, typeof([1, 2, 3].s));
> }
> ----
> Something like staticArray([1, 2, 3]) is probably so ugly and way to
> long so that nobody new would like it or use it. We should consider the
> usability. int[$] looks nicer and is shorter. Nobody want to type ugly
> and long names instead.
> Let look at staticArray([1, 2, 3]) as a new user: "I have to call a
> function with an array(whereby it is unclear to the new user if [1, 2,
> 3] is placed on the heap or not) and the result of this call is a static
> array? Why? Is it worth it? Should I use something cumbersome?"
>
> That is why I'm either for the language feature or for something short
> like '[1, 2, 3].s'
>
> And no, nobody want to write 'alias s = staticArray' every time again.
> Don't come with this counter please.

The interesting thing is because of the tight overloading rules, "s" 
will only match statically-sized arrays. So it's okay to simply expose 
it as std.array.s without fear it might clash with other uses of the "s" 
symbol. Awesome. -- Andrei