The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback.

Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword.

Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Few notes:

- Please submit pull requests to adjust the markdown document if you want to propose any improvements (mentioning @WalterBright and @andralex for confirmation).
- The proposal refers to a number of other documents and it is recommended to become familiar at least briefly with all of them.
- At this point the question I'd personally suggest to be evaluated is "does this proposal enable enough useful designs?". A good check would be to try taking some of your projects and see if having DIP1000 approved and implemented could improve them.

On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
> The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback.
>
> [...]

How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant] interact with LDC's GC to stack promotion pass?

On 8/10/2016 4:56 PM, Nicholas Wilson wrote:
> How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant]
> interact with LDC's GC to stack promotion pass?

I don't know about how that works in LDC, but general such a promotion can only be done if the compiler can prove there are no escaping pointers to the data.

On 11/08/2016 8:35 AM, Dicebot wrote:
> The first DIP has just landed into the new queue. It is a proposal from
> language authors and thus it bypasses usual nitpicking process and
> proceeds straight to requesting community (your!) feedback.
>
> Essentially, it is an attempt to solve reference lifetime problem by
> extending implementation of `scope` keyword.
>
> Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>
> Few notes:
>
> - Please submit pull requests to adjust the markdown document if you
> want to propose any improvements (mentioning @WalterBright and @andralex
> for confirmation).
> - The proposal refers to a number of other documents and it is
> recommended to become familiar at least briefly with all of them.
> - At this point the question I'd personally suggest to be evaluated is
> "does this proposal enable enough useful designs?". A good check would
> be to try taking some of your projects and see if having DIP1000
> approved and implemented could improve them.

Question:
I see RefCountedSlice example, does this mean if I alias this say like:

struct FooBar;

struct Foo {
	FooBar* v;

	scope FooBar* get() { return v; }
	alias this get;
}

That it will operate correctly in the below case?

func(myFoo);
void func(scope FooBar*)

If this does work, this is a major addition that I've been waiting for, for my managed memory concept! https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d
After this I'll only need proper ref counting in the language ;)

This bit seems odd:

T func(T* t) {
  return t; // ok
}

Is there an implicit conversion from T* to T?


On Wed, Aug 10, 2016 at 10:05 PM, rikki cattermole via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

> On 11/08/2016 8:35 AM, Dicebot wrote:
>
>> The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback.
>>
>> Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword.
>>
>> Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>>
>> Few notes:
>>
>> - Please submit pull requests to adjust the markdown document if you
>> want to propose any improvements (mentioning @WalterBright and @andralex
>> for confirmation).
>> - The proposal refers to a number of other documents and it is
>> recommended to become familiar at least briefly with all of them.
>> - At this point the question I'd personally suggest to be evaluated is
>> "does this proposal enable enough useful designs?". A good check would
>> be to try taking some of your projects and see if having DIP1000
>> approved and implemented could improve them.
>>
>
> Question:
> I see RefCountedSlice example, does this mean if I alias this say like:
>
> struct FooBar;
>
> struct Foo {
>         FooBar* v;
>
>         scope FooBar* get() { return v; }
>         alias this get;
> }
>
> That it will operate correctly in the below case?
>
> func(myFoo);
> void func(scope FooBar*)
>
> If this does work, this is a major addition that I've been waiting for,
> for my managed memory concept! https://github.com/rikkimax/al
> phaPhobos/blob/master/source/std/experimental/memory/managed.d
> After this I'll only need proper ref counting in the language ;)
>

On 8/10/2016 10:05 PM, rikki cattermole wrote:
> Question:
> I see RefCountedSlice example, does this mean if I alias this say like:
>
> struct FooBar;
>
> struct Foo {
>     FooBar* v;
>
>     scope FooBar* get() { return v; }
>     alias this get;
> }
>
> That it will operate correctly in the below case?
>
> func(myFoo);
> void func(scope FooBar*)

Yes, it better :-)

On 11/08/2016 5:41 PM, Walter Bright wrote:
> On 8/10/2016 10:05 PM, rikki cattermole wrote:
>> Question:
>> I see RefCountedSlice example, does this mean if I alias this say like:
>>
>> struct FooBar;
>>
>> struct Foo {
>>     FooBar* v;
>>
>>     scope FooBar* get() { return v; }
>>     alias this get;
>> }
>>
>> That it will operate correctly in the below case?
>>
>> func(myFoo);
>> void func(scope FooBar*)
>
> Yes, it better :-)

Perfect :)

On 8/10/2016 11:36 PM, rikki cattermole wrote:
> Perfect :)

The nice thing about this scheme is it can do some things that Rust can't (and Rust can do things that this can't). I suppose it will balance out.

This looks like the best proposal so far. Many useful ideas, and at the first glance it looks like a big step forward. I also really like how the useful stack allocation behavior for closures and new'ed values is kept alive.

What would be nice to add is a behavior specification for 'scope' member variables (lifetime considered equal or slightly shorter than parent object lifetime). For example the `RefCountedSlice.payload` and `count` fields could be annotated with 'scope' to let the compiler actually guarantee that they won't be accessible in a way that conflicts with their lifetime (i.e. the 'scope' return of 'opIndex' would actually be enforced).

That will just leave one hole in conjunction with the @trusted destructor, which is (presumably) not easy to fix without much larger changes to the type system, as well as to how container types are built. It is still vulnerable to artificial shortening of the elements' lifetime, e.g. by using opAssign() or destroy():

@safe {
    RefCountedSlice!int s = ...;
    scope int* el;
    el = &s[0];
    s = RefCountedSlice.init;
    *el = 12; // oops
}

A similar issue affects the library implementation of isolated memory that I did a while ago:

@safe {
    class C { int* x; }

    // c is guaranteed to be only reachable through this variable
    Isolated!C c = makeIsolated!C();

    // c.x is a @property that returns a specially wrapped reference to
    // the actual C.x field - with this DIP this is similar to a 'scope'
    // return, but acts transitively
    Scoped!(int*) x = c.x;

    // one of the benefits of Isolated!T is that it allows @safe
    // conversion to immutable:
    immutable(C) ci = c.freeze();
    // c gets cleared by freeze() to disallow any further modifications

    // but, oops, x is still there and can be used to modify the now
    // immutable contents of ci.x
    *x = 12;
}

Disallowing the assignment of scope return references to local scope references (either by default, or using some form of additional inference/annotation) would solve this particular issue, but not the issue in general (the assignment/destruction could for example happen in a nested function call).

On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
> - At this point the question I'd personally suggest to be evaluated is "does this proposal enable enough useful designs?". A good check would be to try taking some of your projects and see if having DIP1000 approved and implemented could improve them.

There's a use-case that relates to some of our discussions together in another context, about structs or classes that borrow data via ref:

    struct MyWrapperStruct (T)
    {
        private T* data;

        public this (ref T input)
        {
            this.data = &input;
        }

        // ... other functionality relies on
        // this.data being valid throughout
        // the lifetime of the struct

        // note, we could probably avoid everyone
        // having to use raw pointers as above if
        // we could use scope properties to create
        // a `Ref` borrowed-pointer type that would
        // complement the existing `Unique`
    }

I don't see any examples touching on this, but it would be very useful for implementing e.g. InputRange structs which cannot be copied by value, yet which need to be usable with UFCS range chains.

Any chance the proposal authors could add some examples of how scope could affect class/struct fields which borrow data by reference (meaning the class/struct instance should not escape the scope of the input data)?