mutable, const, immutable guidelines

Daniel Davidson nospam at spam.com
Wed Oct 16 12:24:22 PDT 2013


On Wednesday, 16 October 2013 at 19:01:59 UTC, H. S. Teoh wrote:
> 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?
>

Thanks. I appreciate any help I can get. Here is a small sample: 
http://pastebin.com/TeiQ9DYa

Other samples have at least 5 levels of composition. I'm 
generating the structure from json schema so I'm looking for 
something that scales and is immune to changes in deeply nested 
members.

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

I understand. It is a shame. If the data source is rich json data 
- I think AAs are a necessity.


More information about the Digitalmars-d-learn mailing list