const / in

[spir]

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?


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com