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