On Tuesday, 16 December 2014 at 01:00:47 UTC, Walter Bright wrote:
On 12/15/2014 5:38 AM, deadalnix wrote:
On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
For me "scopeness" is a property of "view", not object itself
- this also
makes ownership method of actual data irrelevant. Only
difference between GC
owned data and stack allocated one is that former can have
scoped view
optionally but for the latter compiler must force it as the
only available.
Ha finally something start to make sense here.
Well, the DIP does defined scope in terms of a 'view' in just
this manner.
I am obviously terrible at explaining things.
Don't you think there is a contradiction between this notion of
"view" and being so focused on lifetimes? Does it make sense to
explicitly throw away lifetime information and then spend a lot
of effort on preventing lifetime-violating assignments to take
place?
The current proposal is either too limiting or not limiting
enough.
Too limiting, because programmers expect to gain something for
making parameter types explicit. A naive "make no assumptions
view" is more suitable as a default, then let the programmer
specify the specifics where possible/needed, but you need to
figure out the specifics first and let the "make no assumptions
view default" be the leftovers…
The proposal is not limiting enough, because retaining knowledge
about allocation order and aliasing brings important benefits:
An ordered "linear" parameter type would have properties such as:
- being aliasfree
- being on the stack, and cheaply checkable against the stack
pointer
Sure, ref counting is fairly general for dynamic tracking, but it
is also quite expensive. A check against the stack-pointer is
much cheaper.
I think the uncanny valley metaphor that was brought up was quite
good. If you are going to put in constraints on references, then
do it in a manner that is easy to deal with and which brings
benefits such as aliasfree references. If constraints become
"arbitrary" then usability will suffer and it will seem pointless
to put in extra work to use them.
You have already gone more or less wholesale for templates, so
you might as well use it here as well, to bring substantial
benefits to stack-allocation, because the current proposal is a
very weak in terms of benefits.
