Disappointing inflexibility of argument passing in D

[Tobias Pankrath]

On Tuesday, 11 February 2014 at 16:29:01 UTC, Carl Sturtivant 
wrote:
> On Tuesday, 11 February 2014 at 15:57:33 UTC, Tobias Pankrath 
> wrote:
>> On Tuesday, 11 February 2014 at 15:10:57 UTC, Carl Sturtivant 
>> wrote:
>>> void main() {
>>>      //conversions from string part of the definitions of 
>>> Data, Data2
>>>   f( "hello", "bonjour"); //no way to do this --- 
>>> disappointing
>>> }
>>>
>>> See
>>> http://forum.dlang.org/thread/agstjpezerwlgdhphclk@forum.dlang.org
>>
>> Function calls are a more complicated case because of overload 
>> resolution.
>>
>> If f(string, string) is defined, this will a) break silently 
>> or b) require qualification. Both is disappointing, too.
>
> I do not understand why your (a) and (b) provably must be so. 
> Please supply an argument: there seem to be other possibilities 
> and without a proof that there are not, we may as well seek to 
> do the right thing.

I have code  that executes f(Data, Data), but I'm actually 
passing (string, string). Now someone of my coworkers defines 
f(string, string), which is visible to my code. I see two 
possibilities: My codes executes the new function f, which 
silently brakes my program or the compiler says that two possible 
overloads are in place and requires explicit qualification of the 
correct function (I'm probably back to f(Data(), Data()).

What is the third way you have in mind?

> In the absence of such comprehension on my part, it seems to me 
> that what's needed are some consistent rules that generalize 
> the overloading rules about the interaction of opPass and 
> overloading, with some priorities so that the best match is 
> found. Perhaps some combinations of opPass and overloading 
> should be illegal. Not that I've thought this through. :)

I'm just saying that it is more complicated that simple 
assignment.