On Wednesday, 10 December 2014 at 22:20:37 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 10 December 2014 at 22:05:10 UTC, deadalnix wrote:
>> That is completely off topic. this is a function parameter, you
>> can return scope, and you don't need to know who own the
>> container for that to work.
>
> You have many scopes, if two different scopes pass in "horses" to a function in a recursive chain then you need to know which horse the returned "leg" belongs to…
>
> But by all means… go ahead if you think it is off topic. (it isn't)

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).

deadalnix:

> That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases).

What syntax do you suggest to use if you want to extend it that way later?

Bye,
bearophile

On Thursday, 11 December 2014 at 00:48:32 UTC, bearophile wrote:
> deadalnix:
>
>> That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases).
>
> What syntax do you suggest to use if you want to extend it that way later?
>
> Bye,
> bearophile

scope[symbol_name] would get the same lifetime as symbol_name for
instance. This is only a proposal, I'm not convinced that this is
strictly necessary, and, as long as we know we can add it if
needed, we are good.

On 12/9/2014 10:43 PM, deadalnix wrote:
> On Wednesday, 10 December 2014 at 05:23:29 UTC, Walter Bright wrote:
>> On 12/8/2014 3:21 PM, deadalnix wrote:
>>> On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote:
>>>> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
>>>>
>>>
>>> It can safely be returned if you consider its lifetime as the
>>> intersection of the lifetime of the function's parameter.
>>
>> The only purpose to a 'scope ref' parameter is to say it isn't being returned.
>> 'ref' itself does not escape in any way other than by returning.
>
> That is a completely useless feature. Also, you want to have scope return for
> container like thing.

I disagree. It's critical for chaining one function to the next.

On 12/9/2014 8:34 PM, Dicebot wrote:
> But as far as I understand the spec it will result it this code failing too:
>
> auto r = ["aaa", "bbb", "ccc"].map!foo;
> // should compile but will fail because foo returns scope  ref:
> string s = r.front;
>
> What I mean is that in current proposal it is impossible to transfer scope
> information down the call chain - either function always returns scope ref or
> never. Which implies the necessity of something like `auto scope`...

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.

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.

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.

On 2014-12-04 09:24:13 +0000, Walter Bright said:

> 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.

I like the basics of the proposal and I think it's the right direction. HOWEVER, I strongly believe that function arguments should be scoped by default and `impure` when they take reference which they will keep.

-Shammah

On 2014-12-04 10:00:28 +0000, Walter Bright said:

> On 12/4/2014 1:51 AM, eles wrote:
>> On Thursday, 4 December 2014 at 09:25:11 UTC, 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.
>> 
>> Making it implicit and requiring an explicit "escape" for un-scoped variables?
>> 
> 
> Was afraid that would break too much code.

No, this is super important.  Break it all!  This kind of change will significantly increase the performance of D code by almost eliminating GC thrashing.

Having to type scope EVERYWHERE will make it unused and therefore unusable in other people's libraries.

-Shammah.

On 2014-12-11 07:03:58 +0000, Shammah Chancellor said:

> On 2014-12-04 09:24:13 +0000, Walter Bright said:
> 
>> 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.
> 
> I like the basics of the proposal and I think it's the right direction.  HOWEVER, I strongly believe that function arguments should be scoped by default and `impure` when they take reference which they will keep.
> 
> -Shammah

Also, more feedback.   I would suggest that scope variable are the default inside of functions as well as parameters.   Using escape analysis, instead of them being errors, make them warnings and implicitly make them impure.

-Shammah