On Thursday, 10 October 2013 at 23:12:24 UTC, qznc wrote:
The linked page clearly says "It may, however, be changed by
another reference to that same data."
usually you would think that no one else should change the
data while callee runs. but at least with c++ i could imagine
running callee in a thread with a reference to a const thing
which changes underneath and while callee is running.
A const argument gives information to both sides. For the
caller it means callee does not modify the data. For the callee
it means somebody else (another thread) may modify the data at
any time.
An immutable argument means the same for the caller, but gives
an additional guarantee to the callee that nobody modifies the
data.
That is probably a reasonable interpretation... but I think it
will only get you pain. The fact is, regardless of your
interpretation of "const" arguments - the general guideline is
"prefer const because immutables and mutables can be passed in".
Think of it this way: you are writing a very generic function
that requires inputs that you do not mutate. If you choose
immutable you are making your life easier, I guess, since you
know data is not being changed on you. But you are also
preventing your function from being called by any arguments that
are already mutable (assuming the type has mutable aliasing)
because crossing the mutable to immutable divide is not part of
the language. So, the only way then for mutable types to make it
into your function is to copy them and this may or may not even
be possible. And if you truly know no code is mutating your data
it is a tougher sell.
On the other hand if you go with const parameters, your data
could in fact change on you. Unfortunately, it can cause terrible
angst when the only options make you wish for other options.
Have you actually written nested D data types with mutable
aliasing (not just slices but assoc arrays) and used immutable in
the signatures? I have tried and not succeeded.
I guess this just highlights the need for guidelines.
