D's greatest mistakes

[Steven Schveighoffer]

On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

No, that's not what I'm saying.  Creating a language-based tail-const  
solution *unifies* all references, including any smart references you can  
create.  I can say tail-const anything and it always means the same  
thing.  It's another tool to allow creating of smart references.  Without  
this, we have to special case tail-const in all smart reference types.  If  
anything Rebindable is a special case smart reference, it only addresses  
class tail-const.  The language solution addresses general tail-const.  
E.g. how does Rebindable address tail-const ranges?

I see it 100% opposite from what you are saying, a library solution looks  
to me like "look! we don't have to change the language to add language  
features, all you need is this template that adds 10k of bloat to your  
exe!  And why do you need to pass them as parameters, just create a new  
local variable?  And why do you need it to work with *all* reference  
types, there's other syntax for that!"  All for the sake of not changing  
the language, which I think is the more direct and complete solution.  I  
don't really understand the resistance.

>
>> To go with your analogy, we own the bank (compiler), we can print our
>> own money...
>
> And we all know where that takes.

Better compiler?  Better smart references?  Yep, I agree :)

-Steve