const / in

[Jonathan M Davis]

On Saturday 11 December 2010 04:33:07 spir wrote:
> Hello,
> 
> 
> Just stepped on the const faq page at
> http://www.digitalmars.com/d/2.0/const-faq.html. Illuminating :-)
> 
> But I really wonder about the following topic:
> 
> ==============================
> Why aren't function parameters const by default?
> 
> Since most (nearly all?) function parameters will not be modified, it would
> seem to make sense to make them all const by default, and one would have
> to specifically mark as mutable those that would be changed. The problems
> with this are:
> 
>    1. It would be a huge break from past D practice, and practice in C,
> C++, Java, C#, etc. 2. It would require a new keyword, say mutable.
>    3. And worst, it would make declarations inconsistent:
> 
>       void foo(int* p) {
>          int* q;
>          ...
>       }
> 
>       p points to const, and q points to mutable. This kind of
> inconsistency leads to all sorts of mistakes. It also makes it very hard
> to write generic code that deals with types.
> 
> Using in can mitigate the ugliness of having to annotate with const:
> 
> void str_replace(in char[] haystack, in char[] needle);
> ==============================
> 
> Well, about the last note, sure: 'in', for me, just means 'const' for a
> parameter. So that the note just translates the question to "Why aren't
> function parameters _in_ by default?"... Thus, commenting the three point
> above:
> 1. Right. (But never breaking just means never progressing, and
> transporting the same design errors from language to language forever.) D1
> --> D2 was the right opportunity for this, esp considering the threading
> topic below. 2. Yes, precisely! We need _this_ keyword, not 'const' or
> 'in', for the rare cases (?) where it makes sense to mutate a parameter or
> any other local variable. 3. No! Why then make local variables mutable by
> default?
> 
> The only case where we need to mutate a local var is in loops (accumulators
> and loop-local vars), like: mutable int sum = 0;
> 	mutable int n;
> 	foreach (s : strings) {
> 	    n = to!int(s);
> 	    sum += n;
> 	}
> I would be very happy with such a constness scheme. Make the right thing
> easy, and the special case explicit. Alternativaly, the compiler may
> detect vars used in loops and automagically allow their mutation, which
> would get rid of 'mutable'. (Alternatively, the whole feature of loop
> blocks like done in imperative languages is a design choice. If such loop
> block get away, mutables get away as well.)
> 
> 
> 
> The same doc states:
> =============================
> Why does D have const?
> [...]
>    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.
> =============================
> 
> Great. But this whole big thing is sadly weakened by the choice of making
> locals mutable by default. Else, most D funcs would so-to-say be
> "naturally" threading-friendly. And detecting unsafe ones would be (for
> programmers and compilers as well) as difficult as noting an occurrence of
> 'mutable'. Or do I miss the point?

Making anything const by default is too big a break from C/C++/Java/C#/D1/etc. 
to have any hope of getting any traction. There are some folks around here who 
would love that to be the case, but it would break all code ever written in D, 
require big changes to the language, and make porting code from other languages 
a lot more of a pain.

Mutation is used so often and is so vital to how D works that if you were to 
flip-flop it so that const or immutable were the default, then you'd have to be 
marking many - possibly most - of your variables as mutable.

Also, in many cases, there is no real point to const. For function parameters 
which are value types, you don't really gain much by making them const or in in 
except helping the compiler know that you don't intend to alter the variable. 
This will help catch accidental mutation, and it may help the compiler figure out 
what and how to optimize, but a smart compiler shouldn't even need that help, 
and the gain is likely minimal. The same goes for local variables.

const matters most for reference types, because it helps guarantee that 
variables that you pass to other functions or return from a function aren't 
altered by the code that gets it.

immutable is important because it allows you to share data between threads 
without worrying about locks and the like. But that gain with threads is pretty 
much nil for local variables unless you send them to another thread via message 
passing.

Switching to scheme where const or immutable is the default would not make the 
compiler any smarter or better. It could figure out the exact same stuff that it 
figures out now. In some code, there would be a gain, but mostly const is to help 
the programmer make sure that something doesn't get modified when you pass it to 
something else. It's an aid to the programmer. Most programmers will _not_ want 
const to be the default, and they aren't used to thinking that way, so such a 
change would do the complete opposite of aid the programmer in most cases.

I like const. I use it a lot. I try to make as many member functions const as I 
can. I even declare many local variables as const or immutable in the hopes that 
it will help the compiler better optimize my code. But I think that it would be 
an _big_ mistake for C-based language to make const the default. It would be too 
big a break with other C-based languages. And as for a language like D that's 
already a ways along? It would an absolutely _enormous_ mistake to do it - even 
for something like D3. The gains are minimal. You'd turn off a _ton_ of 
programmers. You'd break a _lot_ of code. And porting code would become that 
much more of a nightmare.

It has definitely been suggested before that const should be the default, and 
some people would love that, but there's no way that it's going to happen in D2, 
and much as I like const, I think that it would be a huge mistake to do it in 
any version of D and likely any version of any C-based language. It's too big of 
a break with other versions of D and other C-based languages.

- Jonathan M Davis