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.
