Generic const - a non-functional view

Walter Bright newshound1 at digitalmars.com
Tue Jun 24 15:54:27 PDT 2008


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.


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

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.


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

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



More information about the Digitalmars-d mailing list