On Monday, 29 January 2018 at 12:10:16 UTC, Simen Kjærås wrote:
Consider this case:
immutable(int)[] a = [1,2,3];
immutable(int)* b = &a[1];
You're free to slice the array or pop elements off its front or
back, but if you change the order of elements, the value that b
points to will change. D does not allow this.
You can create a new array with the elements moved into the
locations you want, and with another layer of indirections
(int*[]) you can move the elements of the array without
mutating the values.
Ooh my... yes I can understand that. And I guess immutable is
implicitly convertible to const and then if you can move const
stuff then you have that problem. From the FAQ, my general
understanding is that const is there as a bridge from immutable
to mutable as a promise that the memory under this symbol will
not be altered by that reference.
While experimenting a bit I came across this though which,
currently, I do understand that value of
struct Int {
const int value;
}
void main() {
Int i0 = Int(0);
Int i1 = Int(1);
Int i2 = Int(2);
Int[3] arr0 = [i0, i1, i2];
Int[] arr1;
arr1 ~= i0;
arr1 ~= i1;
arr1 ~= i2;
arr1[0] = i0; // nope, Error: cannot modify struct arr1[0]
Int with immutable members
}
So if a struct has a struct that has any member const, then
effectively that whole struct is a const (well immutable it
seems, so not even const)? Is that really correct? What is this
sorcery? If yes I find it very surprising, but I don't think I'm
very clear on what D is trying to solve with const ... yet.
I find const a little hard to swallow so far. From what I
understand, it's good for function parameters, and as a function
attribute for functions that return temporaries, except don't use
it with ranges (i.e. don't put it on front). Actually not sure
about function attributes on second thought. So... function
parameters and local variables that you know won't change is what
I'm going to go with for now.
Also hasMobileElements!(const int[]) is true, so that means I
can move elements around right?
hasMobileElements checks if the value of front can be moved as
in move constructors, not as in 'can be moved to a different
spot in the range'. I will admit the name does little to
unconfuse this point.
I'm not following here :s If value of front can be move
constructed, then something can take it's place no?
Thank you!
