Range over a container r-value with disabled postblit

Nordlöw per.nordlow at gmail.com
Sun Jan 14 21:57:37 UTC 2018


On Sunday, 14 January 2018 at 14:04:46 UTC, kinke wrote:
> That sounds reasonable. For something like `foreach (e; 
> makeRange().wrapRangeByRef())`, referencing the makeRange() 
> struct rvalue by pointer in the wrapped range won't work, as 
> the underlying range lifetime ends with the foreach range 
> expression, while the wrapped range's lifetime extends to the 
> end of the foreach loop. So making the wrapped range take 
> ownership of a range rvalue by moving it into a member (of 
> ByRvalueElement) makes sense IMO.
> Lvalues aren't moved implicitly by the compiler, so referencing 
> them by pointer (&this) is safe.

Thanks for confirmation, kinke.

Further, if we add the new trait(s)

__trait(isLvalue, symbol)
__trait(isRvalue, symbol)

or perhaps simply just

__trait(isRvalue, symbol)

that can be applied with symbol being `this` to make this static 
code branching work inside member functions such as opSlice 
aswell. What do you think of such an addition?

Note that __trait(isLvalue, this) cannot be used to detect 
whether `this` is an l-value or an r-value, which I find strange.


More information about the Digitalmars-d-learn mailing list