Const template

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Sat Jan 20 18:15:52 PST 2007


Jarrett Billingsley wrote:
> "Andrei Alexandrescu (See Website For Email)" 
> <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:45B2A3AE.20408 at erdani.org...
>> It's all too simple to protest against various features that other 
>> languages have bastardized and throw the all too simplistic "So what, D is 
>> now becoming Xyz?" as an argument in the discussion.
> 
> Well how long has Walter been anti-implicit casting?  It just seems like 
> he's been "no overloading opCast for more than one type" and "implicit 
> casting and construction are bad things" and "opAssign is the devil" for so 
> long, and then just recently he seems to have had a change of mind.. what 
> happened?

It happens to us all to associate some bad consequences with some 
wholesale cause without investigating further. Many of the perceptions 
above are based on various degrees to which C++ embarked on implementing 
them and partially failed because an understandable lack of clear 
foresight. To exemplify:

* "no overloading opCast for more than one type" and "implicit casting 
and construction are bad things" came from C++ having made implicit 
conversion the default one (and the only possible one when converting to 
built-ins), thus making implicit conversions springing all over the 
place in expressions. To assuage that, C++ also added the bizarre rule 
that maximum one user-defined conversion can act in one expression. 
This, coupled with the byzantine overloading rules of C++, contributed 
to a general perception that implicit conversion is a bad idea.

However, numerous use cases show that implicit conversions are 
expressive as long as they are the result of a conscious decision. 
Besides, the core does support implicit conversions, and I think history 
of programming languages has shown copiously that the dictum "Quod licet 
Iovis, non licet bovis" doesn't apply to language design.

* "opAssign is the devil" stems from a simple confusion - that 
assignment and copy construction are strongly related. They aren't, and 
as soon as this was clarified, opAssign made its way into the language. 
Copy construction suffers of an infinite regression problem that C++ 
avoided, arguably in quite a disingenious way that has caused much 
grief, to be assuaged by the upcoming rvalue references (which come with 
the unneeded complexity specific to afterthought designs). I fear that 
solving inout for D will have a similar stench.


Andrei



More information about the Digitalmars-d mailing list