On Thursday, 4 July 2013 at 20:11:56 UTC, TommiT wrote:
> struct DynamicArray(T)
> {
>     void opOpAssign(string op : "+")(int n) { }
> }

That was supposed to be:

struct DynamicArray(T)
{
    void opOpAssign(string op : "~")(T value) { }
}

On Thursday, 4 July 2013 at 20:11:56 UTC, TommiT wrote:
> 
> C++ never accepts anything but an exact match between the parameter types of the instantiated template function and the types of the arguments passed in to the function at the call site which caused the instantiation.

Although, that's not exactly true. C++ accepts an inexact match when the instantiated parameter is either a reference or a pointer to a public base class of the passed argument type. I.e. there is an is-a relationship.

On Thursday, 4 July 2013 at 20:11:56 UTC, TommiT wrote:
>
> I have never seen any DMD code. My deduction of how DMD _must_ work is based on:
> 1) my understanding of how template instantiation works in C++
> 2) the fact that the call to foo(sa) does compile

And this is a problem, because many of such naive judgemnets are actually false.

> The compiler simply must know about implicit conversion of static to dynamic arrays during template instantiation, or otherwise it wouldn't be able to do the instantiation of foo for the call to foo(sa).

Implementation may do other way, at first instantiate template (with deduced type) and then try to plug arguments as in case of non-template function (including implicit conversion). If it cannot, implementation issues error message for a particular problem and then general "template error instantiation".

>  And not only that, the compiler must accept a non-exact match between parameter and argument types. C++ never accepts anything but an exact match between the parameter types of the instantiated template function and the types of the arguments passed in to the function at the call site which caused the instantiation. That's pretty simple logic, which is why I'm confident that I'm right even though, like I said, I don't know anything about how DMD is written.

D forums are not the right place to show confidence in C++ knowledge. What are your points regarding type deduction and implicit conversion in D?

On Thursday, 4 July 2013 at 20:43:45 UTC, Maxim Fomin wrote:
>
> Implementation may do other way, at first instantiate template (with deduced type) and then try to plug arguments as in case of non-template function (including implicit conversion). If it cannot, implementation issues error message for a particular problem and then general "template error instantiation".

Well, it doesn't really matter how it is implemented. What matters is that the implicit conversion does happen.


> What are your points regarding type deduction and implicit conversion in D?

I thought my point would have been made painstakingly clear by now. My point is that D behaves in a way that's very different from C++ or any other language which does heterogeneous translation of type parameters. And I've never seen any mention of this neither in the spec nor in TDPL (nor have I seen this discussed before). This difference should be mentioned somewhere newcomers are guaranteed to see it.

On Thursday, 4 July 2013 at 21:31:43 UTC, TommiT wrote:
> On Thursday, 4 July 2013 at 20:43:45 UTC, Maxim Fomin wrote:
>>
>> Implementation may do other way, at first instantiate template (with deduced type) and then try to plug arguments as in case of non-template function (including implicit conversion). If it cannot, implementation issues error message for a particular problem and then general "template error instantiation".
>
> Well, it doesn't really matter how it is implemented. What matters is that the implicit conversion does happen.

Issue in this case is not that it happens per se (of course, it does), but whether implicit conversion influences type deduction. As it was mentioned previously about particular example, it does not.

>
>> What are your points regarding type deduction and implicit conversion in D?
>
> I thought my point would have been made painstakingly clear by now. My point is that D behaves in a way that's very different from C++ or any other language which does heterogeneous translation of type parameters. And I've never seen any mention of this neither in the spec nor in TDPL (nor have I seen this discussed before). This difference should be mentioned somewhere newcomers are guaranteed to see it.

Please provide evidence which support your point about D. Previous example doesn't do that. Piece of dmd implementation is appreciated. Otherwise claims about what implementation does are of little value.

On Friday, 5 July 2013 at 02:45:47 UTC, Maxim Fomin wrote:
> On Thursday, 4 July 2013 at 21:31:43 UTC, TommiT wrote:
>> On Thursday, 4 July 2013 at 20:43:45 UTC, Maxim Fomin wrote:
>>>
>>> Implementation may do other way, at first instantiate template (with deduced type) and then try to plug arguments as in case of non-template function (including implicit conversion). If it cannot, implementation issues error message for a particular problem and then general "template error instantiation".
>>
>> Well, it doesn't really matter how it is implemented. What matters is that the implicit conversion does happen.
>
> Issue in this case is not that it happens per se (of course, it does), but whether implicit conversion influences type deduction. As it was mentioned previously about particular example, it does not.

Of course implicit conversion influences type deduction. If it didn't, if implicit conversion didn't have any say in type deduction, then the call foo(sa) would not compile. The compiler needs to know, and thus has to be influenced by the knowledge of implicit conversion, in order to be able to deduce T to be int.


On Friday, 5 July 2013 at 02:45:47 UTC, Maxim Fomin wrote:
>>
>>> What are your points regarding type deduction and implicit conversion in D?
>>
>> I thought my point would have been made painstakingly clear by now. My point is that D behaves in a way that's very different from C++ or any other language which does heterogeneous translation of type parameters. And I've never seen any mention of this neither in the spec nor in TDPL (nor have I seen this discussed before). This difference should be mentioned somewhere newcomers are guaranteed to see it.
>
> Please provide evidence which support your point about D. Previous example doesn't do that. Piece of dmd implementation is appreciated. Otherwise claims about what implementation does are of little value.

The evidence of that D behaves differently from C++ is that foo(sa) compiles. I only talked about a possible implementation of it in DMD in order to explain this thing to you. But the actual implementation of it in DMD doesn't matter.