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.
