questions around mutating range algorithms, const, and return ref

Ali Çehreli acehreli at yahoo.com
Tue Jan 30 09:51:18 UTC 2018


On 01/30/2018 12:17 AM, aliak wrote:

 > 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)?

No, it cannot be assigned but the other parts of the object can be mutated.

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

It's the same with C++: A type with a const member cannot have a 
compiler-generated assignment operator.

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

'const' as a member function attribute is meaningful: It makes the 
implicit 'this' parameter const. Same as a function parameter attribute 
in that regard.

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

I'm not happy that I can answer that question. At least I opened a bug 
about some part of the confusion recently. :)

   https://issues.dlang.org/show_bug.cgi?id=18036

Ali



More information about the Digitalmars-d-learn mailing list