DIP69 - Implement scope for escape proof references
Dicebot via Digitalmars-d
digitalmars-d at puremagic.com
Mon Dec 15 01:28:42 PST 2014
On Monday, 15 December 2014 at 06:12:05 UTC, Walter Bright wrote:
> C++ seems to do fine without it for const. It's a convenience
C++ const does not really restrict or affect anything "for real",
it is non-existent feature. `scope` as proposed would result in
inability to store result of predicates if those are ever to
accept scope data - unless you defined two versions for each
function that may possibly accept scope data with absolutely
>>> 2. This is what scope inference is all about.
>> Which only works with templates and lack of scope on arguments
>> does not affect
>> function body -> templates are not necessary, same as inout.
> It also works with all the lambdas, since source for them is
> always available. I also wanted to make it (i.e. inference)
> work with auto functions, but Don Clugston was the primary
> objector :-)
This is not really answering my objections but side-stepping. I
do support attribute inference. I would actually support full
attribute inference in the language (and help convincing Don
about it ;)) if it was introduced as foundation of the language
and not arbitrary hack (== rethink the way .di interfaces and
static libraries are defined)
> I do view inference as something we need to extend to more
That would help with many issues but it need careful design to be
well-accepted. How about teaming up to do a DIP about it at some
point where this discussion is over? :P
>>>> 2) at least optional transitivity to be able to express to
>>>> protect with scope
>>>> data referenced by slice or owned linked list referenced
>>>> from root node.
>>> 1. that won't work unless scope is a type constructor
>> I know and this is why I am leaning toward it being qualifier
>> despite all
>> related issues.
> That would be a truly massive change to D, and I'm not at all
> sure it would be worth it. We've (i.e. Kenji) have been fixing
> bugs with inout for years, and idea that had seemed
Yes, I know and this why I am leaning towards that path but
willing to accept any storage-class based solution - as long as
it fits my basic criteria. I wonder if some hybrid approach is
possible - for example, keep it storage class but pretend
anything transitively accessible though it as if it was of scope
storage class on its own. But that quickly gets into "exceptions
for special cases" land :(
>>> 2. it can be achieved by using wrappers that only allow
>>> by-scope references to
>>> their data (RC is an example of such a wrapper)
>> It is viral approach and backwards incompatible one - we can't
>> change signatures
>> of Phobos functions to return Wrapped!(char) instead of
>> char for example.
>> While theoretically possible I can't call this approach
>> practical - not until
>> see some convincing application example.
> But you can change signatures to add annotations?
Such annotation would only prevent from compiling code which was
already undefined by documentation. Changing return type (which
wasn't Voldemort type before) may break any program that has
lines akin to `char data = foo()` - perfectly legal working
>> This sounds totally against my understanding of scope. I want
>> scope exactly to
>> prohibit such actions. However it is possible in slightly
>> modified way - where
>> you don't directly insert pointer to AST but use public method
>> of AST control
>> structure that checks if supplied scope pointer belongs to
>> list of nodes it
>> owns and casts away scope after that.
> Wrappers do that, too.
> I know that 'wrapper' sounds bad to you, but one of the goals
> of D's UDT's is to make it easy to adapt the behavior of a type
> by wrapping it in a struct, rather than build new behavior into
> the language.
Problem is that our UDT are simply not that good enough yet.
Wrappers are fine in general but I want to wrap for less common
cases and support more common ones natively. I suppose this is
your intention too but we disagree on what is actually the common
case and what is the special case.
More information about the Digitalmars-d