D's greatest mistakes

[Jonathan M Davis]

On Tuesday, November 30, 2010 10:38:43 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.
> 
> >> 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 :)

Personally, I think that an in-language solution would definitely be better and 
more in line with other language features than trying to fix the issue in a  
library. This really does look like a core language issue which we couldn't 
solve properly, so we created a bandaid in the standard library to solve it.

The problem is that the feature has to be properly designed and that someone has 
to take the time to actually implement it. And at this point, even if we have a 
perfect solution for it, Walter is sick of the whole issue and not at all 
interested in implementing it. Someone else would need to step up to the plate 
on this one, and we don't exactly have an abundance of dmd developers. It seems 
like no one has both the inclination and the time to do it.

I'd _love_ to see proper tail const as a language feature, and that's where I 
think that it should be, but it really doesn't look like that's going to happen 
at this point.

- Jonathan M Davis