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