const

[Bill Baxter]

Walter Bright wrote:

> I understand your and others' frustration with const, and here's what I 
> think it is based on:
> [...]
> 3) [...]
> 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.

This is very true.  I think you would have lost a lot fewer of us if 
there were some actual cohesive explanatory documentation of the latest 
design.

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

Or maybe, despite the weaknesses it manages to cover 95% of cases that 
arise, and thus it represents a good trade-off between guarantees and 
ease-of-use.

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

That sounds almost completely wrong to me.  C++ programmers tend to use 
'const' in their function signatures to document the things that 
shouldn't change.  That sounds like self-documentation to me.  What do 
you mean by "rely on convention instead"? Please explain.

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

I dunno about this one.  Java seems to scale pretty well.  The 
long-standing enhancement request asking for const in Java was closed by 
Sun as "will not fix"[1].  They don't seem to think it's a show-stopper.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070


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

Opportunities are great.  But asking everyone to eat their brussel 
sprouts for an indefinite amount of time because of some *potential* but 
not guaranteed future benefit is not going to get many people excited.

If improved optimization is the goal then there are lots of 
opportunities for improvement in D's generation of FP code, for 
instance, or so I've heard.  And those don't require any language 
changes.  Even with fancy language features, can D really hope to 
compete against the likes of Intel and Microsoft or even GCC in the 
category of "best optimizer"?

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

Again talk about potential is great, but until I've seen something more 
concrete I'm very skeptical that adding a dash of invariant into the mix 
is magically going to make D a multi-core champion.  I suspect it will 
require very careful use of invariant in the parts of code you want to 
make parallel, and so it won't be just a magical switch that suddenly 
makes all your code run 10x faster.  It'll be something that requires 
careful planning to take advantage of.

I'm also doubly skeptical because if easy parallelism was the goal, an 
implementation of something akin to OpenMP should be possible even in 
D1.0.  It doesn't require const/invariant.  OpenMP works fine with C. 
It may not do everything that's possible in the grand vision, and may 
require more user intervention to employ, but it doesn't get much 
simpler than slapping a "#pragma pfor" in front of a for loop and having 
it automatically parallelized.  And probably a lot of the thread 
management infrastructure would be similar to what is required by any 
grand vision anyway.  So it wouldn't be wasted effort, I don't think.

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

"Just use 1.0" is only a temporary solution.  You have to phase out D1.0 
at some point.  D is niche enough already without the dilution of having 
two major, incompatible versions.

And arguments to just ignore const don't really work due to the viral 
nature of const.  If you want to use a const-correct library, you will 
notice it when the library returns a const something to you, and you 
find you can't do anything with it unless you cast away const.  But then 
you've entered into undefined territory and your program can no longer 
be considered correct.  If you're a library writer then there will be 
pressure on you to make your libraries const-correct.  Therefore most 
libraries will eventually end up being const-correct, and people who 
want to ignore const will have very few alternatives.  I've seen very 
few C++ libraries that don't at least try to be const-correct.

For "just ignore const" to be a realistic recommendation there would 
need to be a "just ignore const" switch in the compiler.

--bb