mutable, const, immutable guidelines

[Joseph Rushton Wakeling]

On 11/10/13 01:43, Daniel Davidson wrote:
> 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".

Which makes much sense for code that is intended to be generically useful.

> 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.

If you are insisting that your function receive immutable inputs, you are in 
turn constraining the user of that code.  If you really want your function to be 
"generic", isn't the appropriate thing to allow the user the choice of whether 
they want to pass it immutable data, or to take the risk of passing it mutable data?

Surely there's a tradeoff -- you may well feel the resulting safety is worth it, 
and there may be other benefits, such as optimizations, that you can derive from 
having only immutable data.

But for the standard library of a multiparadigm language, it's not appropriate 
to force users to use immutable data.

> 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.

Well, that depends.  If you go with const parameters but you pass it immutable 
data, you know it won't change on you.  You, the user, are in control.

> 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.

Yes, I tried it, and ran into this problem.  But generally these days I use "in" 
to mark arguments that are not intended to be modified.  I personally prefer 
that -- it has a semantic meaning, and how it translates into code is for the 
compiler.

> I guess this just highlights the need for guidelines.

Guidelines are always nice. :-)