On 2014-12-05 15:27:41 +0000, Steven Schveighoffer said:

> On 12/4/14 4:24 AM, Walter Bright wrote:
>> http://wiki.dlang.org/DIP69
>> 
>> Despite its length, this is a fairly simple proposal. It adds the
>> missing semantics for the 'scope' storage class in order to make it
>> possible to pass a reference to a function without it being possible for
>> it to escape.
>> 
>> This, among other things, makes a ref counting type practical. It also
>> makes it more practical to use other storage allocation schemes than
>> garbage collection.
>> 
>> It does not make scope into a type constructor, nor a general
>> type-annotation system.
>> 
>> It does not provide an ownership system, though it would complement one.
> 
> Can we take a step back here?
> 
> I read many people's comments and I understand only about half of them.
> 
> Can someone who knows what this new feature is supposed to do give some Ali Çehreli-like description on the feature? Basically, let's strip out the *proof* in the DIP (the how it works and why we have it), and focus on how it is to be used.
> 
> I still am having a hard time wrapping my head around the benefits and when to use scope, scope ref, why I would use it. I'm worried that we are adding all this complication and it will confuse the shit out of users, to the point where they won't use it.
> 
> -Steve

This is exactly why this feature should be default behavior with compiler warnings generated when things escape scope.

The basic idea is that most things should be on the stack and go away when the stack goes away.   The proposal codifies how the compiler should infer that references to variables which are to be placed on the stack are not escaping their scope.   The benefit is that the GC has to do *way* less work from what it has to do now for most of the use cases of D.

-Shammah

On 12/10/2014 8:56 PM, deadalnix wrote:
> On Thursday, 11 December 2014 at 03:27:08 UTC, Walter Bright wrote:
>> I disagree. It's critical for chaining one function to the next.
>
> I one can't return, one can't chain.

I guess I'm not seeing the problem.

On Thursday, 11 December 2014 at 07:30:03 UTC, Walter Bright wrote:
> On 12/10/2014 8:56 PM, deadalnix wrote:
>> On Thursday, 11 December 2014 at 03:27:08 UTC, Walter Bright wrote:
>>> I disagree. It's critical for chaining one function to the next.
>>
>> I one can't return, one can't chain.
>
> I guess I'm not seeing the problem.

a.foo().bar() is the same as bar(foo(a)), that is, using the returned value as first parameter. If you can't return, you can't chain.

On Wed, 10 Dec 2014 23:06:13 -0800
Shammah Chancellor via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> > Was afraid that would break too much code.
> No, this is super important.  Break it all!
alas, not in this life. each "break our code" just making resistance harder. ;-)

On 12/10/2014 11:55 PM, deadalnix wrote:
> On Thursday, 11 December 2014 at 07:30:03 UTC, Walter Bright wrote:
>> On 12/10/2014 8:56 PM, deadalnix wrote:
>>> On Thursday, 11 December 2014 at 03:27:08 UTC, Walter Bright wrote:
>>>> I disagree. It's critical for chaining one function to the next.
>>>
>>> I one can't return, one can't chain.
>>
>> I guess I'm not seeing the problem.
>
> a.foo().bar() is the same as bar(foo(a)), that is, using the returned value as
> first parameter. If you can't return, you can't chain.

Right, and you can chain when the declarations are:

scope ref S foo(ref T a);
U bar(ref S s);

a.foo().bar(); // works

On 12/10/2014 10:43 PM, Dicebot wrote:
> On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright wrote:
>> If you want data to 'escape' from r.front, then it shouldn't be marked as
>> scope. Definitely, using scope successfully will require some rethinking of
>> how code is written.
>
> Allowing or prohibiting escaping of r.front in that example depends on
> definition of mapped range. There is nothing to "rethink" about it - case is
> almost identical to const+inout.

One reason why with templates, they'll do scope inference.

On Thursday, 11 December 2014 at 00:35:46 UTC, deadalnix wrote:
> It is always safe to consider scopeness of the retrun value (if marked scope) as being the intersection of the lifetime of parameters.
>
> That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases).

Linear typing is already extremely limiting, by limiting it even further you end up with something annoying. You basically get a version of memory safety that does not solve any typical memory unsafe situations.

By having pointers that do scope-depth-tracking you do at least get a generic solution that can be optimized away when possible. The D authors have to accept that you need to embed ownership in pointers if you want memory safety and convenience, or that you have to provide means to guide the semantic analysis. You need one or the other, or both, but you cannot pretend that you can do without.

Arbitrary constraints are annoying, not convenient. If I as a programmer know that something is safe, then the compiler should accept it, and the language should allow me express it.

On 11.12.14 08:25, Shammah Chancellor wrote:
> This is exactly why this feature should be default behavior with
> compiler warnings generated when things escape scope.
>

It can be compiler switch escape=I(gnore)|W(arning)|E(rror).

On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote:
> On 12/4/2014 1:51 AM, eles wrote:
>>
>> Making it implicit and requiring an explicit "escape" for un-scoped variables?
>>
>
> Was afraid that would break too much code.

Compiler switch: escape=I(gnore)|W(arning)|E(rror).
For transition default Ignore.

On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/7/2014 6:12 AM, Dicebot wrote:
>>
>> But from existing cases it doesn't seem working good enough. For example,
>> not
>> being able to represent idiom of `scope ref int foo(scope ref int x) {
>> return x;
>> }` seems very limiting.
>
>
>   scope ref int foo(ref int x);
>
> will do it.

Will it? It looks like foo can't be called with scope data?


>> I also don't consider `ref` design as a storage class any kind of success
>> at all
>> and generally agree with Manu on this topic. At the same time alternative
>> proposals that make it a qualifier (like Marc did) do impact existing
>> language
>> much more and this no small concern.
>
>
> My experience with C++ ref as type qualifier is very, very bad. It's a special case EVERYWHERE. Doing type deduction with it is an exercise in a completely baffling set of rules and a different rule for every occasion - Scott Meyers has a great piece on this.
>
> There are probably only a handful of people on the planet who actually understand C++ ref. I wished very hard to avoid that with D ref.

I do completely sympathise with you on this point. I understand where
you were coming from on 'ref', and I do applaud the effort. Nobody
said that ref should be just the same as C++, but I am saying that the
D solution is not a success.
I'm all about a ref that improves on C++, but I don't think that's
what we have. We have something that's just complex and unwieldy in a
different (and for my money, even more frustrating) way.

I'm just saying, don't repeat that mistake with scope! There must be another way...

I'm also quite uneasy with the fact that scope would not be transitive as a storage class. What happens when it's applied to a value type, like a struct, that contains some pointers? An adaptation wrapper for a single pointer is super common; ie, a tiny struct passed by value with scope needs to have it's contained pointer receive the scope-ness of the argument.

I don't have the perfect proposal, but I feel very strongly about 2 things:
1. It must not be a storage class; the concept was a disaster with
ref, and I struggle with this more frequently than any other 'feature'
in D.
2. I feel it's a big mistake to separate it from the type system,
which I think most agree, is D's greatest asset by far. Manipulating
types is simple and convenient using the type system, and I think
manipulating scope will be just as important as any other attribute as
soon as even slightly complex use cases begin to arise.