D's greatest mistakes

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Nov 30 10:24:37 PST 2010


On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
> On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> I agree that the problem is difficult but disagree with the angle.
>> This is not the challenge, and it is not only mine to take. To the
>> extent we're interested in making D a successful language, we're all
>> on the same boat, so the challenge belongs to us all.
>>
>> Adding a new type constructor to the language or generally a new
>> feature is always possible, but has a high cost. Half of the community
>> throws their hand in the air with each new feature, and the other half
>> throws them in the air for each feature that could have been. The key
>> is to navigate such that as many good designs are expressible as
>> easily as possible.
>>
>> The real challenge is to solve the problem within the global set of
>> constraints we have, not to prove that a language feature would solve
>> it. I know a language feature would take care of the issue, the same
>> way money would take care of buying a nice house. The challenge is to
>> have a nice house when money _is_ limited.
>
> IMO opinion, the cost of modifying the language so that a library
> solution that half-solves the problem is possible, in order to create a
> template that handles all sorts of odd cases is far greater than a new
> keyword that would also enable things like tail-const ranges.

I'm not at all convinced. The general issue at stake is creating smart 
references. Any inroads into solving that enables entire new classes of 
designs. You're saying, forget smart references, let's create a special 
smart reference.

> To go with your analogy, we own the bank (compiler), we can print our
> own money...

And we all know where that takes.


Andrei


More information about the Digitalmars-d mailing list