www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Disappointing inflexibility of argument passing in D

reply "Carl Sturtivant" <sturtivant gmail.com> writes:
D has opAssign, making defining implicit conversions from any 
type to a new type possible on assignment, so where is the 
analogue (say opPass) for passing an argument to a function?

void f( Data d, Data2 d2) { ..... }

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
Feb 11 2014
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
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.
Feb 11 2014
parent reply "Carl Sturtivant" <sturtivant gmail.com> writes:
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.

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. :)

But is there a good reason why there isn't a reasonable such set 
of rules in principle? And if not, why do we not have opPass? 
Overtly converting all over the place is less than a happy 
situation.
Feb 11 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
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.
Feb 11 2014
parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 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?


Concretely the latter sounds right in that specific case, but I
have not endeavored to design new overloading rules that include
the effects of opPass.

Overloading should be confined to one module (I distantly recall
there is some restriction in this area). And when overloading,
knowledge of how the rules apply to the existing functions of the
same name should be used by the function writer.

Actually there are already conversions, like passing int to long.
How do they interact with overloading? This is a prototype of
sorts. This already causes the kind of overloading interference
in your example.

opPass provides a property of a data type, and anyone using that
type should know about such a property before writing functions
that take arguments of that type.

People writing overloaded functions with types alien to types
with opPass should be aware of the overloading rules, and should
search for functions that may compete with their overload,
including looking for opPass conversions in parameter types of
such functions. Documentation should reveal such conversions to
help out. Overloading is usually not a problem anyway, because
people keep it simple.

opPass is too important to refuse because now it's possible for
it to cause some minor trouble if care isn't taken to notice
which function(s) I am overloading!

Carl.
Feb 11 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 7:10 AM, Carl Sturtivant wrote:

 D has opAssign, making defining implicit conversions from any type to a
 new type possible on assignment, so where is the analogue (say opPass)
 for passing an argument to a function?

 void f( Data d, Data2 d2) { ..... }

 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


Hmmm... very interesting. I was thinking of the same these days because 
we have qualifier(T[]) automatically change to qualifier(T)[] upon 
passing to a function. However, there is no way for the user to specify 
such type change for a user-defined type.

Adding some sort of opPass would help solve the current problem we have 
with passing const ranges into functions. (Currently they won't work 
unless they're built-in slices).


Andrei
Feb 11 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 11 February 2014 at 16:38:41 UTC, Andrei Alexandrescu
wrote:

 Hmmm... very interesting. I was thinking of the same these days 
 because we have qualifier(T[]) automatically change to 
 qualifier(T)[] upon passing to a function. However, there is no 
 way for the user to specify such type change for a user-defined 
 type.





 Adding some sort of opPass would help solve the current problem 
 we have with passing const ranges into functions. (Currently 
 they won't work unless they're built-in slices).


Is is not simply for functions. It is for any user defined type
that embed a parametric types.

This is why can't have a nice container library.
Feb 11 2014
prev sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Tuesday, 11 February 2014 at 15:10:57 UTC, Carl Sturtivant 
wrote:

 D has opAssign, making defining implicit conversions from any 
 type to a new type possible on assignment, so where is the 
 analogue (say opPass) for passing an argument to a function?

 void f( Data d, Data2 d2) { ..... }

 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


In the meanwhile maybe you can try a workaround with templates? 
Something like:

void f(D1, D2)(D1 d, D2 d2) if (is(D1:Data) && is(D2 : Data2))
{
    // Temp vars and assignment
    ...
    ...
    f(tmpD1, tmpD2);
}
Feb 11 2014
parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 In the meanwhile maybe you can try a workaround with templates? 
 Something like:

 void f(D1, D2)(D1 d, D2 d2) if (is(D1:Data) && is(D2 : Data2))
 {
    // Temp vars and assignment
    ...
    ...
    f(tmpD1, tmpD2);
 }


Yes, that does the job.
Feb 11 2014