DMD 1.031 and 2.015 templates

[Steven Schveighoffer]

"Lars Ivar Igesund" wrote
> Walter Bright wrote:
>
>> Lars Ivar Igesund wrote:
>>> Walter Bright wrote:
>>>
>>>> Some new stuff to make writing templates easier.
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.030.zip
>>>
>>> (Wrong zip link ^)
>>>
>>> Something broke, probably due to the fix in 617 and/or 1383:
>>>
>>> Given
>>>
>>> T[] layout(T) (T[] output, T[][] layout ...)
>>>
>>> the following code
>>>
>>> T[] format(T) (T[] output, Time t) {
>>>
>>> T[] convert (T[] tmp, long i)
>>> {
>>>     return Integer.formatter!(T) (tmp, i, 'u', 0, 8);
>>> }
>>>
>>> return layout (output, "%0, %1 %2 %3 %4:%5:%6 GMT",
>>>                             Days[date.dow],
>>>                             convert (tmp[0..2], date.day),
>>>                             Months[date.month-1],
>>>                             convert (tmp[2..6], date.year),
>>>                             convert (tmp[6..8], time.hours),
>>>                             convert (tmp[8..10], time.minutes),
>>>                             convert (tmp[10..12], time.seconds)
>>>                            );
>>> }
>>>
>>> results in
>>>
>>> :template layout(T) does not match any template declaration
>>> :template layout(T) cannot deduce template function from argument types
>>>
> (wchar[],char[25u],wchar[],wchar[],wchar[],wchar[],wchar[],wchar[],wchar[])
>>
>> Can you make a standalone test case, please?
>
> The standalone test case works fine if I append 'w' to the literal, so 
> seems
> like that is a no :) However, prepending it with cast(T[]) seems to be an
> acceptable workaround though.
>

So basically, the issue is that D is not inferring the type of the string 
literal based on the context.  In the D spec, it implies that the type can 
be inferred (http://www.digitalmars.com/d/1.0/lex.html):

"The optional Postfix character gives a specific type to the string, rather 
than it being inferred from the context. This is useful when the type cannot 
be unambiguously inferred, such as when overloading based on string type"

I'm guessing that this implies that normally, it CAN be inferred from the 
context, although this is not specifically stated (should it be?).  It seems 
unambiguous in the example that the type of T should be whatever type 
'output' is.  Therefore, IFTI should interpret T as being wchar, which 
should imply that the literal should be a wchar[].

-Steve