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