Request: a more logical static array behavior

[Tommi]

On Thursday, 15 August 2013 at 13:25:58 UTC, Maxim Fomin wrote:
> On Thursday, 15 August 2013 at 12:12:59 UTC, Tommi wrote:
>>
>> Implicit conversion VS Implicit conversion during type 
>> deduction
>> ----------------------------------------------------------------
>> I don't think that you failed to see the distinction between 
>> these two things, but because someone might, I'll talk about 
>> this a bit more.
>>
>> This is regular implicit conversion (nothing weird or magical 
>> about it):
>>
>> void foo(int[] da) { }
>> int[3] sa;
>> foo(sa); // implicit conversion
>>
>> This is implicit conversion during type deduction (totally 
>> weird and magical):
>>
>> void foo(T)(T[] da) { }
>> int[3] sa;
>> foo(sa); // implicit conversion during type deduction
>>
>
> Please stop spreading this misconveption. There is *no*
> conversion during type deduction. There is *a check* whether 
> base
> type of static array is same as base type of dynamic array which
> happens to be true in this case. *Conversion* happens in
> completely related compiler part.

I've been saying "implicit conversion during type deduction", but 
I seriously doubt that anyone who knows what type deduction is, 
would think that actual implicit conversion somehow happens 
during that.

(Type deduction is simply figuring out what the actual type of a 
templated type is given a certain context).

But, from now on, I'll use the phrase "checking for implicit 
conversions during type deduction" instead of "implicit 
conversion during type deduction".

On Thursday, 15 August 2013 at 13:25:58 UTC, Maxim Fomin wrote:
> And there is no special about it during template type deduction.
> This (meaning that base type of int[N] array is same as base 
> type
> of int[] array) happens or could happen in any stage of 
> compiling
> proccess. How C++ does it is irrelevant to what D does.

I agree that what C++ does is irrelevant to what D does (I never 
said it was). I used an example of C++ code to make a point which 
_is_ relevant to D. Since you seemed to miss the point, I'm going 
to translate that previous C++ example code D code now to get my 
point across:

struct DynamicArray(T) { }

struct StaticArray(T, size_t n)
{
     DynamicArray!T opImplicitCast() const
     {
         return DynamicArray!T();
     }
}

void foo(T)(DynamicArray!T da) { }

void bar(DynamicArray!int da) { }

void main()
{
     StaticArray!(int, 5) sa;
     bar(sa); // OK: implicit conversion
     foo(cast(DynamicArray!int) sa); // OK: explicit conversion
     foo(sa); // Error: No matching function call to 'foo'
}

Don't try to compile that, it won't work because I used the 
opImplicitCast operator which is a future feature of D (it 
provides an implicit conversion for used defined types). How do I 
know it's a future feature of D? Don't ask... okay, you got me... 
I'm a time traveller.

Now, to fulfill my promise of being excruciatingly explicit: What 
said before about being a time traveller, it was a joke. My point 
is that D could have an implicit cast operator in the future. And 
if it did have it, then it would become obvious to everybody why 
it is that a static array, such as:

int[5]

...is magical, that is, it is fundamentally different from:

StaticArray!(int, 5)

...in that whereas the above code example would _not_ compile, 
this next example would (and it does) compile:

void foo(T)(T[] da) { }

void bar(int[] da) { }

void main()
{
     int[5] sa;
     bar(sa); // OK: implicit conversion
     foo(cast(int[]) sa); // OK: explicit conversion
     foo(sa); // OK !!! (compare to the previous example)
}