mutable, const, immutable guidelines

[H. S. Teoh]

On Wed, Oct 16, 2013 at 08:49:51PM +0200, Daniel Davidson wrote:
> On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
> >On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
[...]
> >>If you have a type that has now or may ever have in the future any
> >>mutable aliasing (e.g. inclusion of T[] or T1[T1] where Ts are
> >>mutable) do not ever use the immutable keyword in any context as
> >>things just break down.
> >
> >Yes, because immutable means nothing, no one, can change the data
> >after it's constructed, ever. If you want mutable aliasing, what you
> >want is const, not immutable.
> >
> 
> I think the term "mutable aliasing" and "what you want" don't work
> together. "mutable aliasing" is not about context of usage or what
> you want, it is a compile time attribute of a struct. I want to use
> associative arrays in composition because I think they are the way I
> view and use my data. `struct T { string[string] i; }` has mutable
> aliasing, like it or not. So, it is not so much that I want mutable
> aliasing - in fact I fear it. But once you use AAs it is a fact of
> life.
[...]
> Is the suggestion here: use immutable in any composition context
> where you have slices and you want to not "worry about mutable
> aliasing". So, do like string does: any case where you have T[] as a
> member, prefer immutable(T)[] since then you don't have to worry
> about sharing. Well, not sure that works in general because the T in
> string is char and has no mutable aliasing itself. Suppose T itself
> has mutable aliasing, then what? Or, suppose it is a struct with no
> mutable aliasing *now*. Who's to say it won't change.
> 
> So, where does all this leave us w.r.t. a good set of guidelines?

Sorry, I kinda barged into this conversation, so I'm not sure what
exactly you're trying to achieve here. What kind of composition contexts
do you have in mind? Maybe you could help me understand what you're
trying to do?

Keeping in mind that AA's, as they are currently implemented, leaves a
lot of room for improvement, to say the least. So you might be running
into some AA-related issues, not the type system proper.


T

-- 
Creativity is not an excuse for sloppiness.