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

[Andrei Alexandrescu (See Website For Email)]

Kevin Bealer wrote:
> 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.

This should work. Also because D creates symbol tables "in parallel" - 
all symbols in a module are defined conceptually simultaneously, benefit 
that I momentarily forgot about :o).

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

Makes sense.

Andrei