D's greatest mistakes

[Steven Schveighoffer]

On Tue, 30 Nov 2010 15:47:22 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 11/30/10 12:38 PM, Steven Schveighoffer wrote:

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

It affects them all as much as Rebindable affects them all.  Either way,  
it's something new they have to learn, whether it's a language feature or  
a library feature.  This argument makes no sense.

Another way to look at it -- whichever solution is used is really going to  
affect only library writers, not library users.  Whether the user writes:

@tail const(C);

or

Rebindable!(const(C))

or something else is really irrelevant to them, what's relevant is what  
hoops do I as a library writer have to jump through to get this damned  
thing to work seamlessly.

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

To determine whether tail-const is useful or not, let's examine all uses  
of tail-const and tail-immutable in phobos that *don't* involve classes.   
I.e. const(T)[] arrays, and const(T)* pointers.

Rebindable does not work, that much I do know.  Pointing at lack of use of  
Rebindable is not proof of anything except that it's a half baked feature.

I also don't know that tail-const references will be mainstream useful or  
just useful on a small scale.  I know that it directly affects the project  
I wrote.  As of now, dcollections containers are const-unfriendly because  
to implement const would require massive duplication of all ranges and  
functions that accept ranges, plus implicit casting just doesn't work  
between two different template instantiations that vary only on const.

Whether the language is modified so this can work, or the language  
incorporates tail-const directly, it's a problem that needs to be solved  
IMO.  Which is the right answer, I don't know, but the builtin explanation  
seems to me to allow more efficient code, and less boilerplate required.

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

Why is the frequency questionable?  Isn't every use of string an example  
of tail-immutable?  Isn't string used everywhere?

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

I'm not at all proclaiming victory because Rebindable sucks.  I think  
something that allows Rebindable to properly work would be great for  
something less commonly used than tail-x, but I'd rather have the code be  
cleaner for a feature that's used everywhere.  We could do away with array  
syntax, or operators, and just go with function calls and elemAt(size_t),  
but I swear and punch things every time I have to use C#'s arrays,  
lamenting for how D's syntax works.  Syntax is important too.

If you can make Rebindable!(T) become tail const for every type of T  
(including a range), and have it work flawlessly when casting to/from  
const(T), then I accept that as a valid solution.  If Rebindable just  
solves the tail-const class case, and I have to do something *like* what  
Rebindable does whenever I want to allow tail-const on any type, then I  
think the problem is not yet solved.

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

Non-nullable is a different animal.  Non-null types do not really exist  
everywhere in D.  Tail-const/shared/immutable types exist everywhere in  
D.  There is no lack of consistency in D for non-nullable types.

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

How does this translate to the software analogy?  What does bankruptcy for  
dmd mean?

Note that we can print our own money and not have to pay it back, it's  
software :)

-Steve