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