Should we remove int[$] before 2.067?

Foo via Digitalmars-d digitalmars-d at puremagic.com
Fri Jan 30 11:18:57 PST 2015


On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu 
wrote:
> 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

Exactly. ;)


More information about the Digitalmars-d mailing list