Type inference and overloaded functions

[Namespace]

On Tuesday, 10 December 2013 at 07:46:25 UTC, Jonathan M Davis 
wrote:
> On Tuesday, December 10, 2013 08:29:02 Kenji Hara wrote:
>> On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
>> >> On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
>> >> > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
>> >> >> I just found weird D behavior about inference of array
>> >> >> types.
>> >> >> 
>> >> >> Let's suppose we have these overloaded functions:
>> >> >> 
>> >> >> import std.stdio;
>> >> >> 
>> >> >> void bar(const(int[3]) arr)
>> >> >> {
>> >> >> 
>> >> >>       writeln("static array");
>> >> >> 
>> >> >> }
>> >> >> 
>> >> >> void bar(const(int[]) arr)
>> >> >> {
>> >> >> 
>> >> >>       writeln("array slice");
>> >> >> 
>> >> >> }
>> >> >> 
>> >> >> // In main we have something like that:
>> >> >> int main(string[] args)
>> >> >> {
>> >> >> 
>> >> >>       bar([1,2,3]);
>> >> >>       writeln(typeof([1,2,3]).stringof);
>> >> >>       return 0;
>> >> >> 
>> >> >> }
>> >> >> 
>> >> >> Weird thing is that the static array version of bar is
>> >> >> called,
>> >> >> but typeof().stringof is int[], not int[3].
>> >> > 
>> >> > Array literals are always dynamic arrays. int[3] is a 
>> >> > static
>> >> > array.
>> >> > 
>> >> > - Jonathan M Davis
>> >> 
>> >> The original question is valid then: [1,2,3] goes to the
>> >> static array
>> >> overload.
>> > 
>> > Then AFAIK, that's a bug. The type of array literals is 
>> > always
>> > a dynamic
>> > array, so they should match dynamic array overloads rather 
>> > than
>> > static array
>> > overloads, or if they match both due to an implicit 
>> > conversion,
>> > there should
>> > be an ambiguity error. Choosing the static array overload 
>> > over
>> > the dynamic one
>> > is just plain wrong.
>> 
>> This is an intended behavior. An array literal has dynamic 
>> array
>> type *by default*.
>> But all of literals in D behave as polymorphic.
>> 
>> char c = 'A';   // character literal has char type by default
>> dchar d = 'A';  // but it may be implicitly typed as 
>> wchar/dchar
>> 
>> string str = "hello";
>> dstring dstr = "hello";  // string literal is implicitly typed 
>> as
>> dstring
>> 
>> int[] darr = [1,2,3];
>> int[3] darr = [1,2,3];   // implicitly typed as int[3]
>> 
>> So, an array literal [1,2,3] is implicitly convertible both to
>> int[] and int[3].
>> And, int[3] is more specialized than int[], so overload
>> resolution will choose the first 'bar'.
>
> I'd argue that it would be far better to give an ambiguity 
> error rather than
> silently pick one over the other. In general, having a literal 
> of any kind
> pick a particular overload when it can match multiple is just 
> begging for
> trouble.
>
> - Jonathan M Davis´
I use this implict converting to static arrays very often and if 
we deprecate it, we really need something to declare static array 
literals.
Since [1, 2, 3] is always dynamic we need something like C's {1, 
2, 3} (But that would maybe conflict with struct literals).

@Kenji
But eben if [1, 2, 3] is implicit converted to int[3], it is 
still allocated on the heap, right?