const

Walter Bright newshound1 at digitalmars.com
Thu Mar 27 13:18:23 PDT 2008


I appreciate the time and effort you made to explain your thoughts. I'll 
try and answer them.

Benji Smith wrote:
> CONST
> 
> Const is a total trainwreck, and is the biggest reason for me to stay 
> away from D in a real project. Even now, nearly a year after the 
> introduction of const/final/invariant, there are still NG threads with 
> more than a hundred posts with people trying to understand how const is 
> supposed to work and how they can accomplish (really simple) goals under 
> the current const regime.
> 
> Before the advent of the various const implementations, I could glance 
> at a function declaration and know exactly what it meant. Now it takes 
> much more effort to understand even the most const-aware functions and 
> develop a strategy for working with them in an application.
> 
> Even if I liked the current semantics, everything still seems so 
> up-in-the-air with const, I'd be loathe to dive in until it stabilized. 
> And I don't see that happening anytime soon.
> 
> It seems like most of the people weighing in on the const debate are 
> trying to figure out a type system and a set of operations that will 
> support all possible use cases. (Like the recent "const debacle" thread.)
> 
> It seems like const will either become too complex for ordinary usage 
> (and will be worked-around more often than used properly) or it will 
> become too weak to be enforce absolute safety/optimization guarantees.
> 
> Personally, I'd rather have no concept of const at all than adopt any of 
> the implementations that have been proposed so far.


I understand your and others' frustration with const, and here's what I 
think it is based on:

1) We worked hard on what is the right way to do const for a year. This 
included at least 3 very different implementations of const that were 
released. The first two turned out to be very wrong and unworkable, and 
we learned from that how to do it right. The problem is, we burned up a 
lot of goodwill with it. Many people simply tuned out with "const is 
bad". Many of the rest bring baggage from the previous const regimes 
along that impair understanding of the current const regime.

2) The current const regime came with a number of bugs in the 
implementation of it that further messed up peoples' understanding of 
what it was all about and how it was supposed to work. Most of these 
have been fixed, but they've still left a bad taste and even more people 
have tuned out with "const is bad".

3) The const regime is completely based on the idea of transitivity of 
const. The problem is, D is the *only* language with a notion of 
transitivity in it. A few academics know about it, but hardly any 
practicing programmers. There is essentially no popular literature about 
it. Mention transitivity to an experienced C++ or Java programmer, and 
you'll get a completely blank look.

In other words, not only do we need to explain how transitivity works in 
particular in D, we have to explain what transitivity does and what it 
is good for. For such a foreign concept, this is a tall order. I'm not 
so good at being a teacher, I tend to explain how things work in D by 
saying "it works just like X in language Y except with this little 
tweak." I can't do that with transitive const. Andrei and I have spent 
many, many hours sitting at a table with smart people explaining what 
transitivity is. It is not an easy concept. Hey, I didn't get it for a 
long time, either, which is partly why the first two const regimes in D 
were wrong.

4) The C++ const is ubiquitous and a lot of people are comfortable with 
it, but it turns out that few understand what it guarantees and what it 
doesn't. C++'s const is so weak that it is more of a convention than a 
guarantee. This weakness enables things to be done with it that are just 
fundamentally unsound, and contribute to C++ being a very difficult 
language to write and verify sound code in.


So, with all these things working against D const, there ought to be 
some compelling reasons for us to swim against the tide and say it's 
worth it:

1. It makes function interfaces more self-documenting. Without 
transitive const, for all pointer/reference parameters one must rely on 
the documentation (which is always missing, out of date, or wrong). Note 
that without transitivity, C++ const is nearly useless for such 
self-documentation, which is why C++ programmers tend to rely on 
convention instead.

2. It makes for interfaces that can be relied upon, which becomes 
increasingly important the more people that are involved with the code. 
In other words, it scales very well. People who are involved with 
projects with large teams of programmers tell me that lack of const 
makes their lives difficult because they cannot rely on the compiler to 
enforce convention. The larger the team, the worse it gets. Managing 
APIs is critical to a large project - it's why BASIC doesn't scale (for 
an extreme example).

3. Const transitivity makes for some interesting optimization 
opportunities. The value of this has not been explored or exploited.

4. Here's the biggie. Points 1..3 are insignificant in comparison. The 
future of programming will be multicore, multithreaded. Languages that 
make it easy to program them will supplant languages that don't. 
Transitive const is key to bringing D into this paradigm. The surge in 
use of Haskell and Erlang is evidence of this coming trend (the killer 
feature of those languages is they make it easy to do multiprogramming). 
C++ cannot be retrofitted to supporting multiprogramming in a manner 
that makes it accessible. D isn't there yet, but it will be, and 
transitive const will be absolutely fundamental to making it work.


Of course, if you're writing single-threaded one man programs of fairly 
modest size, const is not particularly useful. I quite agree with that. 
And in D you can effectively ignore const by just not using it, or by 
using D 1.0. The only place const is imposed is with the immutable 
string type.



More information about the Digitalmars-d mailing list