D's greatest mistakes

[Andrei Alexandrescu]

On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
> 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.

Understanding the "resistance" is very simple. Right now a lot of 
current readers cheerily ignore this thread. Also a lot of potential 
users couldn't care any less. Once the feature will be in the language, 
it will affect them all.

When we defined the const system, we had some goals: guaranteed 
immutability, simple unification of functional and procedural, economy 
of means. We were well aware of the tail const issue, and we made the 
executive decision that we will punt on it on account of it being 
relatively rare in practice, and partially addressable with Rebindable. 
As of this time I don't know whether that is true or not.

Now say we define @tail const or whatever. That serves a case of 
questionable frequency with an in-language solution that affects anyone 
learning the language. This is a huge deal. I don't understand your not 
understanding.

So please let's look into what the limitations of library-based 
solutions are. We shouldn't be triumphantly proclaiming that Rebindable 
is insufficient or inadequate. We should be looking into ways of making 
it and other library solutions work, and understand that relying on an 
in-language solution would be defeat, not victory. Every problem that 
makes Rebindable not work also invalidates other useful designs. 
Conversely, relying on a narrow language change that builds Rebindable 
into the language definition would address the occasional tail-const 
situation but will miss the train on many other, larger, issues.

Same discussion goes about non-nullable. We don't need the compiler to 
understand non-nullable types, we need to imbue the compiler with the 
ability to enforce arbitrary user-defined state invariants, non-null 
being one of them.

>>> 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 :)

I meant bankruptcy.


Andrei