On Sunday, 22 September 2013 at 16:15:09 UTC, Daniel Davidson
wrote:
[...]
3) Also, is storing immutable(STUFF) in a struct in the
general
case (as opposed to just this one) useful or silly?
[...]
I don't really understand the _tail-const_, _tail-immutable_
argument. Why is _tail-const_ fine but not _const_ when there
is transitivity anyway?
[...]
If right out of the gate the feeling is member variables should
not be const or immutable, doesn't that greatly reduce the
value of the mutability specificiers? Members are used to hold
onto the data for the lifecycle of the object and if those
should not make claims or guarantees on mutability then that
seems a shame.
By marking the tail of the member const -- e.g. const(int)[] --,
you're committing to not altering the refered-to data. This
means, the user of your struct can put in mutable and immutable
data.
When you mark it full-const -- const(int[]) -- you're taking away
from the user the ability to make it refer to some other data. In
particular, setting a variable of your struct type to a new value
requires mutable members. There may be special cases where that
extra restriction is desired, but I can't think of one. Unless
you're in such a special case, it just hurts the user for no
reason.
And when the user needs a const object, they can do that on their
own:
struct S {int x;}
const s = S(42);
static assert(is(typeof(s.x) == const));
