On 12/4/2014 6:56 PM, deadalnix wrote:
On Friday, 5 December 2014 at 00:32:32 UTC, Walter Bright wrote:
On 12/4/2014 3:04 PM, deadalnix wrote:
So as mentioned, there are various problem with this DIP :
- rvalue are defined as having a scope that goes to the end of the statement.
That mean they can never be assigned to anything as per spec.
I don't believe this is correct. Rvalues can be assigned, just like:
__gshared int x;
{ int i; x = i; }
i's scope ends at the } but it can still be assigned to x.
It work even better when i has indirections.
I understand what you're driving at, but only a scoped rvalue would not be
copyable.
- It add more special casing with & (as if it wasn't enough of a mess with
@property, optional () and the fact the function aren't first class). For
instance *e has infinite lifetime when &(*e) is lifetime(e).
That's right. I know you're worried about that, but I still don't see it as an
actual problem. (The optimizer makes use of this special case all the time.)
Yes, this is the job of the optimizer to do this kind of stunt.
Not the semantic analysis.
I don't see any other way, nor do I see the practical problem.
I originally had scope only apply to ref, but that made having scoped classes
impossible.
Promoting scoped class on stack is an ownership problem, and out
of scope (!). It make sense to allow it as an optimization.
Problem is, lifetime goes to infinite after indirection, so I'm
not sure what the guarantee is.
The guarantee is there will be no references to the class instance after the
scoped class goes out of scope.
During discussion, I proposed to differentiate lifetime calculation between
lvalues and rvalues (which are inherently different beasts with different
lifetime) and carry (or not) the scope flag with each expression.
I'm not sure how that would be different from the DIP as it stands now.
I cause everything reached through the view to be scope and
obliviate the need for things like &(*e) having special meaning.
Are you suggesting transitive scope?
