• spir (76/76) Dec 11 2010 Hello,

spir <denis.spir gmail.com> writes:

Hello,


Just stepped on the const faq page at http://www.digitalmars.com/d/2.0/cons=
t-faq.html. Illuminating :-)

But I really wonder about the following topic:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
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 t=
o specifically mark as mutable those that would be changed. The problems wi=
th this are:

   1. It would be a huge break from past D practice, and practice in C, C++=

   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 inconsistenc=
y leads to all sorts of mistakes. It also makes it very hard to write gener=
ic 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);
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Well, about the last note, sure: 'in', for me, just means 'const' for a par=
ameter. So that the note just translates the question to "Why aren't functi=
on parameters _in_ by default?"...
Thus, commenting the three point above:
1. Right. (But never breaking just means never progressing, and transportin=
g 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 rar=
e cases (?) where it makes sense to mutate a parameter or any other local v=
ariable.
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 =3D 0;
	mutable int n;
	foreach (s : strings) {
	    n =3D to!int(s);
	    sum +=3D n;
	}
I would be very happy with such a constness scheme. Make the right thing ea=
sy, and the special case explicit. Alternativaly, the compiler may detect v=
ars used in loops and automagically allow their mutation, which would get r=
id of 'mutable'. (Alternatively, the whole feature of loop blocks like done=
 in imperative languages is a design choice. If such loop block get away, m=
utables get away as well.)



The same doc states:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Why does D have const?
[...]
   4. Here's the biggie. Points 1..3 are insignificant in comparison. The f=
uture of programming will be multicore, multithreaded. Languages that make =
it easy to program them will supplant languages that don't. Transitive cons=
t 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 langua=
ges 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 funda=
mental to making it work.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Great. But this whole big thing is sadly weakened by the choice of making l=
ocals mutable by default. Else, most D funcs would so-to-say be "naturally"=
 threading-friendly. And detecting unsafe ones would be (for programmers an=
d compilers as well) as difficult as noting an occurrence of 'mutable'.
Or do I miss the point?


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com