The "opCast" overloading?

[Unknown W. Brackets]

I think the problem with that is simply:

class C
{
	void opCast(out long l);
	void opCast(out int i);
}

C c = new C();
short s = cast(short) c;

What happens?  I would personally say, an error.  But someone will 
always be mad about that.

-[Unknown]


> "Arlen Albert Keshabyan" <arlen.albert at gmail.com> wrote in message 
> news:ejvjgp$2hgk$1 at digitaldaemon.com...
>> Hello Walter!
>> The D language is just a miracle. Sure, you already know about that :).
>> I know the problem of "opCast" cannot be overloaded so far. But I'm sure 
>> there
>> must be a way to do that somehow. That's the question of a semantic. 
>> Right?
>> May we hope it's going to happen soon? I'm asking you the question because
>> you're the Father of D.
> 
> Many people have suggested it, by i.e.
> 
> void opCast(out int x)
> {
>     // put the cast result in x rather than returning it
> }
> 
> Which would allow for overloading by type, but also has the disadvantage 
> that you wouldn't be able to use cast(int)Object as a temporary.  :S
> 
> Frankly, I don't see the need for it.  D isn't trying to be C++, where you 
> can define types which are just as "integrated" into the language as the 
> standard types.  You can't have opAssign, or opDeref or opAddressOf, and so 
> the "boundary" that D classes would have to cross to get to the kind of 
> integration of C++ classes is so large, that allowing overloading of opCast 
> just doesn't seem like it'd do much.  (And to tell you the truth, I wouldn't 
> really want to see it either!)
> 
> The convention in D is instead to have "toType" methods which take the place 
> of a cast.  I.e. toString, toInt, toOtherClassType etc. 
> 
>