A request: templated opCast() signature for class/struct

[Kevin Bealer]

Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> Pragma wrote:
>>> The problem, for the uninitiated, is that D cannot overload by return 
>>> type.
>>
>> I think I understand the problem, and what you're trying to do. The 
>> problem is that T opCast(T)() wouldn't operate like anything else in 
>> D, it would be a total hack. I don't know what the right answer is 
>> here, we'll just have to work on it.
>>
>> There are currently no user defined implicit casts, though Andrei has 
>> suggested adding them with something like opImplicitCast().
> 
> Probably the signature for opCast should be:
> 
> void opCast(out T destination);
> 
> which fortunately brings extra motivation to keep "out" in the language 
> :o). "We're all a big family," inout said.
> 
> That wold allow defining multiple _explicit_ casts.
> 
> opImplicitCast should follow a similar signature, or probably the more 
> flexible global:
> 
> void opImplicitCast(T from, out U to);
> 
> and follow the same exact rules are built-in conversions. In other 
> words, in the graph I sent a while ago, the user would be able to put 
> their own types and draw new arrows that add to the graph, 
> indistinguishable from the current arrows. New arrows among built-in 
> types would be possible, but otherwise any arrows having a user-defined 
> type on one end should be allowed.
> 
> The problem with implicit casts is that they fight directly against 
> modularity. I don't know how to make the global signature modular; the 
> member signature is easier to tame.
> 
> 
> Andrei

Maybe the current module (where the cast happens) could be checked for a 
supported cast; then the module of the 'from' type, then the module of 
the 'to' type*.  This would at least bound the locations where the 
definition could go.  It allows multi-module semantics, but disallows 
global semantics.  The modularity problem is lessened a bit.

In a sense, it's like a member signature in that the author of either 
object is involved in writing the cast operation.  There is also some 
precedent for this kind of 'access' because all elements of a module can 
access the fields of the relevant class.

* (My rationale for checking the 'from' type first is that your opCast 
signature is likely to use an exact 'to' type, but may define the 'from' 
type in generic terms.  It's more important to avoid losing data at the 
source by accidentally picking signature matching a base class when a 
more specific version is available.)

Kevin