mutable, const, immutable guidelines

[H. S. Teoh]

On Wed, Oct 16, 2013 at 09:45:09PM +0200, Daniel Davidson wrote:
> On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
[...]
> >I think any usage of immutable with types/entities not initially
> >designed for immutability is an potential mistake and in that
> >sense it is good that change has broken the user code. Same goes
> >for operating on immutable entity in generic code as if it is a
> >value type without actually checking it via introspection.
> 
> I don't disagree. Now, what does it mean to "initially design for
> immutability" and what are the guidelines. I thought that was kind
> of what we were talking about here. How to effectively use const and
> immutable.

I'd say that user code should use const, not immutable (unless the
library provides a way of constructing immutable instances of the type,
of course), because immutable makes assumptions about implementation
details, which should not be known unless you break encapsulation. As a
user of a properly encapsulated type, I can't make any guarantees about
its immutability; the best I can do is to promise I don't change it
myself -- i.e., const.

Immutable should be used in library code to provide strong guarantees to
the user: since you're the one responsible for implementing the type,
you're in the position to make guarantees about its uniqueness (and
hence, immutability).


[...]
> One general idea that was presented by Ali is that an immutable
> parameter means that not only are you guaranteeing that you will not
> change your data, but also that no one else, even in another thread
> will. That sounds appealing. After all, who doesn't want the data
> they are using in a function to not change from underneath them?

I'm actually wary of this view, to be honest. An immutable parameter
means you expect your *caller* to provide you with a value that cannot
be changed, not by you, nor by anybody else, ever. Sure, it's nice to
have, but that imposes a rather high bar on your callers. They have to
be responsible to guarantee that whatever they hand to you cannot be
changed by anything or anyone else, at any time. If they can do this,
then great; if not, they won't be able to call your function.


> Suppose you have highly structured, deeply nested reference data you
> read from a nosql DB. Surely there is opportunity and some benefit
> to use immutable? The result of the query is just a read only data
> source. But then that data will be consumed - presumably by
> functions with either immutable or const parameters. If all
> signatures use const then when can you benefit from the fact that
> the data is really immutable (by the time it gets to a function with
> const parm the fact that it really was/is immutable is lost.

I'm of the view that code should only require the minimum of assumptions
it needs to actually work. If your code can work with mutable types,
then let it take a mutable (unqualified) type. If your code works
without modifying input data, then let it take const. Only if your code
absolutely will not work correctly unless the data is guaranteed to
never change, ever, by anyone, should it take immutable.

I'm not sure what "benefits" you get from requiring immutable when the
code doesn't really need to depend on immutability. It just makes the
code harder to use (you have to make sure whatever you pass to it is
immutable, and sometimes that's not easy to guarantee, and would require
a lot of copying). Immutable only benefits you when the code *can't*
work correctly unless the data is guaranteed never to change, ever. Hash
table keys come to mind -- if you compute the hash value of the key and
use that to determine which slot to put the data into, it would be very
bad if somebody else mutated that key via a mutable reference after the
fact -- now your AA is broken because the hash value no longer matches
the key.  By requiring an immutable key, you ensure that this never
happens.

Note that in D, everything is thread-local by default unless explicitly
made shared, so using immutable to guarantee other threads won't mutate
the data isn't really necessary.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??