Should we remove int[$] before 2.067?

[Foo via Digitalmars-d]

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.