The "opCast" overloading?

[Burton Radons]

Jarrett Billingsley wrote:
> "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

That's no issue, the compiler already juggles temporary stack variables. 
For example, you can call a method on a struct value result of another 
function call. Maybe you're thinking of something else.

I think the current design was chosen either because it was easy (in the 
then-present compiler) or because it was limited, which are both 
terrible reasons to do it. C++ is absolutely rife with features where 
they tried to implement something but they couldn't do it uniformly so 
the standard's chock full of caveats that will cause innocent-looking 
code (to people who don't fully understand the standard - which is to 
say, everyone except for a few hundred people on the planet) to suddenly 
fail compilation, usually for reasons that make for flatly 
incomprehensible error codes. This is analogous, except instead of not 
having any way to correctly implement the feature, the correct, simple, 
and obvious way is being spurned!

(Note to Walter: I do not want the compiler to solve cast chains at this 
time, but to select the one direct cast which works. Cast overloads in 
every language I know of incorrectly consider all casts to be 
equivalent, so the shortest-path solution is frequently highly ambiguous 
and could severely strip a value if you're not very careful, which you 
can only be (at best) if you control all the source, and so is 
unsuitable for most any collaborative environment. There should be 
discrimination between up casts (casts which add or do not change the 
amount of information in the value) and down casts (casts which strip 
information); one path is better than another if it has fewer down 
casts, fewer up casts on a match of down casts, and failing that is 
ambiguous. An extension would be that an implicit cast is the shortest 
path containing only up casts, which allows us to exactly reproduce all 
casting behaviour in the current language and neatly fit in new types 
without worrying about spastic behaviour or the compiler rejecting code.

As far as I can tell this is a flawless solution to the casting problem 
as while I can theoretically think that there might be two paths with 
the same number of up casts as down casts while having both, I can't 
think of any actual types where that would occur unless if they're 
attempting some silly things like unevenly-applied shortcut casts. 
Ambiguous matches should be VERY rare.)

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

I don't think that's really well-justified. If instead of "foo.toString" 
we could use "cast (char []) foo", that allows us much more flexibility 
in templating, helps to decrease the special nature of certain types, 
allows the programmer more options in how his type is used, and 
eliminates one more place where we have to adorn a function name with 
irrelevant type information. It's all win. There is absolutely no reason 
to follow a "way" if it's the wrong way, or if we were only doing that 
because there was an unintuitive language limitation.

As it is I've never used opCast and in fact it seems very specifically 
useless. Its function is exclusively as syntax sugar; it grants no 
advantages to simply having a method with the same semantics. Worse, it 
confuses the casting issue in objects, because while a cast between 
class types normally results in a reference which is still referring to 
the original object, the opCast function implies (but neither enforces 
nor suggests) that the result will be a completely different object. 
However, the method for casting the object is the same. There's an 
analogous situation in value types where explicitly casting float to int 
(or int to float, which might happen in many templating scenarios) is 
considered equivalent to explicitly casting int to void*, so that you 
cannot automatically discriminate between controllably harmful or 
completely harmless casts casts like the formers and uncontrollably 
/dangerous/ casts like the latter.

This is one of the few cases where C++ got something absolutely god 
damned right, and even worse, where every other language I know of got 
it completely wrong. If two casts do something different or have 
different levels of operation, they MUST have different names or 
different methods of access. So there are different casts for when you 
want to strip the constness from a value, for when you want to change 
the lexical type of a value (things like int to string) which might be 
irreversible as compared to a reversible cast, and so on. Other 
languages either overload cast with multiple operations (which is an 
incorrect use of overloading) or neuter casting so that you can't do 
anything interesting. D miraculously manages to do both simultaneously.

Uh, I've kind of thought a lot about casting, sorry.