D's greatest mistakes

[Jonathan M Davis]

On Tuesday, November 30, 2010 12:47:22 Andrei Alexandrescu wrote:
> 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.

Rare? It's _way_ more useful for pointers and references than full const. I 
virtually _never_ use const pointers to const - in C++ or in D. Tail const is 
almost always the type of const that's useful if you want to pass const anything 
around. Having pointers or references const is rarely useful in comparison. 
That's what's so insanely annoying about final in Java. It makes the exact 
opposite of what is useful to have const be const (the reference rather than the 
referent).

From a syntactical and typing point of view, having tail const built in would be 
highly preferable than having to use Rebindable all over the place. Now, if 
Rebindable could be made to fully work, then that could be acceptable to. But it 
doesn't properly convert to full const right now, and definitely comes across as 
a hack, whether it really is one or not. Tail const is already in the language 
for other types. It's just that it's not there for them all, and that causes 
problems.

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

First and foremost, we _need_ opImplicitCast() for Rebindable to be a fully 
viable replacement for a built-in tail const. Unqual would also need to treat 
Rebindable anything as the core type. I'm guessing that it doesn't right now 
(though I'd have to check to be sure). That may or may not be enough to fix the 
issue with tail const references, I don't know, but it's a big part of it. I 
don't think that it helps at all with tail const and ranges though.

- Jonathan M Davis