Disappointing inflexibility of argument passing in D

[Carl Sturtivant]

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