The "opCast" overloading?

[Reiner Pope]

I don't exactly have much to say; I'm lending my support to an insightful post.

== Quote from Burton Radons (burton-radons at smocky.com)'s article
> (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.)
Differentiating syntactically between up and down casts seems like a very good
idea. As does being able to support implicit casting in user-defined types (Walter
himself has commented on the annoyance of having to write explicit up casts in
other languages like Pascal).

I don't understand, though: you don't seem to want chained casts, yet you describe
how they should work. Why? Also, what is the motivation for chained casts?
Wouldn't they cause more surprising behaviour than help?

> > 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.
I totally agree.

[Other good stuff about casting snipped]

Cheers,

Reiner