Generic const - a non-functional view

[Steven Schveighoffer]

"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> D has a minimal system that is effective - const and invariant. The fact 
>>> that it still seems to cause such misunderstanding is enough evidence 
>>> for me to be very, very wary of adding more complexity to it.
>>
>> Effective only for a feature that doesn't exist yet (pure functions).
>>
>> From my experience, the D const system as it stands now does not cause 
>> such misunderstanding.  Everything is quite clear.  What seems to cause 
>> some misunderstanding:
>>
>> - Why all string library functions require invariant arguments (probably 
>> #1 complaint on NG for newbies trying out D2)
>> - The concept of tail-const pointers and arrays
>> - Why you cannot have tail-const class references
>> - Why you cannot have logical const structures.
>>
>> Explaining const and invariant by itself is easy.  And understandable. 
>> It's the usages of them which are confusing.
>
> If one doesn't understand the usages (and the consequences of) const, then 
> I don't agree that one understands it.

That is a fair point.  But still, there are plenty of features in D already 
that one does not need to understand the syntax of fully in order to use.

>
>
>> But I look at this extension as a sort of 'meta' const.  It's like 
>> templates and mixins.  Some people (not me!) can do magic with these that 
>> would not be possible if templates weren't so wonderfully complex.  But 
>> to use a template that someone wrote isn't even close to as difficult. 
>> For example, the conversion template to(T).  To use it I just do:
>>
>> auto str = to!(string)(5);
>>
>> and I don't have to know how or why it works.
>
> I don't agree that it's ok for library features to be complicated because 
> only advanced users will write libraries. For one thing, it impedes 
> writing libraries (and we all know that proliferation of libraries is 
> essential for D's success) and it presumes that application code is 
> somehow at a level that doesn't need those features.

I think you may have missed my point.  Yes, library proliferation is 
essential for success.  But libraries can be complicated without the need 
for the user of the library to understand them.  Libraries don't have to be 
complicated.  Libraries don't have to use parameterized const for anything. 
But the ability is there if you need it.  I view this no differently than 
templates.  Templates can be complex and very abstract, but very powerful 
and useful.  They also do not need to be fully understood to be used.

> For example, it's really hard to write reusable libraries in C++, and look 
> at the consequences - few reusable libraries exist compared with other 
> languages.

I'd say you are wrong here.

>> Similarly, if a library implements const groups such as lconst like:
>>
>> const alias mutable;
>> alias const!(~mutable) lconst;
>> alias invariant!(~mutable) linvariant;
>>
>> One does not have to understand exactly what they mean.
>
> As an engineer, I prefer to understand my tools completely :-)
> If they aren't understood, and there's an error message, one has no idea 
> what to do.

Sure, so learn the concepts.  I don't think there is any way to create a 
const system that does not require some learning.  Not everyone has read the 
dmd source code, or phobos source code, to find out exactly how it works, so 
not everyone needs to understand the tools they use completely.  In fact, I 
think you would be in the minority.

But my point above is, if you wish to not worry about what const!(X) means, 
you can read the library documentation and only use mutable, lconst, and 
linvariant.

>> All they have to know is 'declare a member mutable if you want it to be 
>> mutable when the class is lconst or linvariant.'  This kind of thing is 
>> easy to document and explain.  One does not HAVE to know all the details 
>> of how these magic generic const structures work, all they have to know 
>> is how to use them.  In fact, they do not need to know much more than 
>> what they already must learn for the current const.  Except that the last 
>> two points of confusion I identified above are removed.
>>
>> In any case, like I said, if you find that it would be difficult to 
>> implement in the compiler, then so be it.  But assuming that you can't 
>> add a feature because it would complicate the language, in light of the 
>> fact that you already complicated the language too much, seems to be a 
>> contradictory argument.  We already have a complicated language by your 
>> measure.  Why not make it a complete language?
>
> I worry about the complexity all the time. The idea is not to make a 
> complicated language, but to find a way to make a simpler language that 
> can do everything we need done. Complexity should only come with a benefit 
> that outweighs the cost of it.

And that is a judgement call you will have to make.  I already get the 
feeling you believe it is not worth it, and that's ok.  At least I put the 
idea out there :)

-Steve