First of all, what exactly is planned for deprecated? It [1] says "Note that scope for other usages (e.g. scoped variables) is unrelated to this feature and will not be deprecated.", but the example...

void main()
{
    A obj;
    {
        scope A a = new A(1);
        obj = a;
    }
    assert(obj.x == 1);  // fails, 'a' has been destroyed
}

... looks a lot like a scoped variable to me, so it's not clear to me what exactly is planned for deprecation. Please clarify.


Ok, with that out of the way, I get why it is unsafe, but isn't it only unsafe because it has not yet been implemented?  Isn't it possible to implement escape analysis and make it a safe and useful feature?

This question was asked before, but never received an answer.[2]

Mike

[1] http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
[2] http://forum.dlang.org/post/k549l4$1s24$1@digitalmars.com

I think the general direction is that scope will be re-purposed as a type modifier for implementing effective borrowing/escape analysis. ...at least, I really really hope that's the plan! :)

On 11 November 2014 09:33, Mike via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> First of all, what exactly is planned for deprecated? It [1] says "Note that scope for other usages (e.g. scoped variables) is unrelated to this feature and will not be deprecated.", but the example...
>
> void main()
> {
>     A obj;
>     {
>         scope A a = new A(1);
>         obj = a;
>     }
>     assert(obj.x == 1);  // fails, 'a' has been destroyed
> }
>
> ... looks a lot like a scoped variable to me, so it's not clear to me what exactly is planned for deprecation. Please clarify.
>
>
> Ok, with that out of the way, I get why it is unsafe, but isn't it only unsafe because it has not yet been implemented?  Isn't it possible to implement escape analysis and make it a safe and useful feature?
>
> This question was asked before, but never received an answer.[2]
>
> Mike
>
> [1] http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack [2] http://forum.dlang.org/post/k549l4$1s24$1@digitalmars.com

On 11/10/14 6:33 PM, Mike wrote:
> First of all, what exactly is planned for deprecated? It [1] says "Note
> that scope for other usages (e.g. scoped variables) is unrelated to this
> feature and will not be deprecated.", but the example...
>
> void main()
> {
>      A obj;
>      {
>          scope A a = new A(1);
>          obj = a;
>      }
>      assert(obj.x == 1);  // fails, 'a' has been destroyed
> }
>
> .... looks a lot like a scoped variable to me, so it's not clear to me
> what exactly is planned for deprecation. Please clarify.
>
>
> Ok, with that out of the way, I get why it is unsafe, but isn't it only
> unsafe because it has not yet been implemented?  Isn't it possible to
> implement escape analysis and make it a safe and useful feature?
>
> This question was asked before, but never received an answer.[2]
>
> Mike
>
> [1]
> http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
>
> [2] http://forum.dlang.org/post/k549l4$1s24$1@digitalmars.com

Well, that's a funny thing. I looked it up, apparently using scope to designate "scope variables" is a thing:

http://dlang.org/attribute.html#scope

" For local declarations, scope implements the RAII (Resource Acquisition Is Initialization) protocol. This means that the destructor for an object is automatically called when the reference to it goes out of scope. The destructor is called even if the scope is exited via a thrown exception, thus scope is used to guarantee cleanup. "

Anyone used to using structs for RAII would think WAT? But a long time ago, structs did not have dtors. So I think at that time, scope simply applied only to classes. Note how it specifically says "objects"

What I think it means is, scope declarations for allocating classes will be destroyed when leaving scope, but will not be allocated on the stack.

I don't know why this is less dangerous. Perhaps it's destroyed but not deallocated?

But the deprecation says "(e.g. scoped variables) is unrelated to this feature." Seems pretty related.

My real guess is that the deprecation message is wrong. We have scope(exit), I don't see why we would need scope variables as well.

-Steve

This is a bit complicated. Originally intention was to deprecate scope variables (scope var = new Class) completely and make people switch to std.typecons.scoped - primarily because of how fragile and inflexible its implementation was (can't have scope fields in aggregates for example)

However it never actually got deprecated and still kind of works with no warnings printed by compiler. Also I remember Daniel mentioning that he uses it extensively in DDMD project which, unfortunately, makes full deprecation unlikely.

There is however a long standing desire to re-purpose `scope` as qualifier for lifetime/ownership semantics which could have made current uses simply a subset of full `scope` implementation. But this is very complicated topic and may take years to fly.

On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote:
> But this is very complicated topic and may take years to fly.

The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =)

On Tuesday, 11 November 2014 at 16:54:10 UTC, ixid wrote:
> On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote:
>> But this is very complicated topic and may take years to fly.
>
> The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =)

It is going to take such long time not because no one considers it important but because designing and implementing such system is damn hard. Prioritization does not make a difference here.

Dicebot:

> ixid:
>> The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =)
>
> It is going to take such long time not because no one considers it important but because designing and implementing such system is damn hard. Prioritization does not make a difference here.

I agree it's a very important topic (more important/urgent than the GC, also because it reduces the need of the GC). But I think Walter thinks this kind of change introduces too much complexity in D (despite it may eventually become inevitable for D once Rust becomes more popular and programmers get used to that kind of static enforcement).

Regarding the design and implementation difficulties, is it possible to ask for help to one of the persons that designed (or watched closely design) the similar thing for Rust?

Bye,
bearophile

On 12 November 2014 04:01, bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Dicebot:
>
>> ixid:
>>>
>>> The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =)
>>
>>
>> It is going to take such long time not because no one considers it important but because designing and implementing such system is damn hard. Prioritization does not make a difference here.
>
>
> I agree it's a very important topic (more important/urgent than the GC, also because it reduces the need of the GC). But I think Walter thinks this kind of change introduces too much complexity in D (despite it may eventually become inevitable for D once Rust becomes more popular and programmers get used to that kind of static enforcement).

I agree. scope is top of my wishlist these days. Above RC/GC, or
anything else you hear me talking about.
I don't think quality RC is practical without scope implemented, and
rvalue temps -> references will finally be solved too.
Quite a few things I care about rest on this, but it doesn't seem to
be a particularly popular topic :(

> Regarding the design and implementation difficulties, is it possible to ask for help to one of the persons that designed (or watched closely design) the similar thing for Rust?
>
> Bye,
> bearophile

On 11/11/2014 18:01, bearophile wrote:
> I agree it's a very important topic (more important/urgent than the GC,
> also because it reduces the need of the GC). But I think Walter thinks
> this kind of change introduces too much complexity in D (despite it may
> eventually become inevitable for D once Rust becomes more popular and
> programmers get used to that kind of static enforcement).

I think Rust's lifetimes would be a huge change if ported to D. In Rust user types often need annotations as well as function parameters. People tend to want Rust's guarantees without the limitations. I think D does need some kind of scope attribute verification, but we need to throw out some of the guarantees Rust makes to get an appropriate fit for existing D code.

For example, taking a mutable borrowed pointer for a variable means you can't even *read* the original variable whilst the pointer lives. I think no one would try to make D do that, but Rust's reason for adding it is actually memory safety (I don't quite understand it, but it involves iterator invalidation apparently). It's possible their feature can be refined, but basically 'mut' in Rust really means 'unique'.

On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:
> On 11/11/2014 18:01, bearophile wrote:
>> I agree it's a very important topic (more important/urgent than the GC,
>> also because it reduces the need of the GC). But I think Walter thinks
>> this kind of change introduces too much complexity in D (despite it may
>> eventually become inevitable for D once Rust becomes more popular and
>> programmers get used to that kind of static enforcement).
>
> I think Rust's lifetimes would be a huge change if ported to D. In Rust user types often need annotations as well as function parameters. People tend to want Rust's guarantees without the limitations. I think D does need some kind of scope attribute verification, but we need to throw out some of the guarantees Rust makes to get an appropriate fit for existing D code.

Have you seen my proposal?

http://wiki.dlang.org/User:Schuetzm/scope

It takes a slightly different approach from Rust. Instead of specifying lifetimes, it uses owners, and it's also otherwise more simple than Rust's system. E.g. there is no full blown borrow checker (and no need for it).

>
> For example, taking a mutable borrowed pointer for a variable means you can't even *read* the original variable whilst the pointer lives. I think no one would try to make D do that, but Rust's reason for adding it is actually memory safety (I don't quite understand it, but it involves iterator invalidation apparently). It's possible their feature can be refined, but basically 'mut' in Rust really means 'unique'.

In my proposal, there's "const borrowing". It still allows access to the owner, but not mutation. This is necessary for safe implementation of move semantics, and to guard against iterator invalidation. It also has other uses, like the problems with "transient range", e.g. stdin.byLine(), which overwrite their buffer in popFront(). On the other hand, it's opt-in; by default, owners are mutable while borrowed references exist.