Re: DIP1000: Scoped Pointers

On Thursday, 18 August 2016 at 17:05:05 UTC, Dicebot wrote: On 08/11/2016 04:38 PM, Sönke Ludwig wrote: 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

Re: DIP1000: Scoped Pointers

On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote: - Please submit pull requests to adjust the markdown document if you want to propose any improvements (mentioning @WalterBright and @andralex for confirmation). Not completely through yet, but it looks really promising. Already made

Re: DIP1000: Scoped Pointers

On 08/11/2016 04:38 PM, Sönke Ludwig wrote: > 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

Re: DIP1000: Scoped Pointers

On Wed, 17 Aug 2016 13:53:37 +0300, Dicebot wrote: > On 08/17/2016 04:01 AM, Chris Wright wrote: >> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: >>> You need to add one more level of indirection for things to start >>> going complicated. >> >> Presumably scope is transitive, so things

Re: DIP1000: Scoped Pointers

On 08/17/2016 04:01 AM, Chris Wright wrote: > On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: >> You need to add one more level of indirection for things to start going >> complicated. > > Presumably scope is transitive, so things shouldn't get horribly complex. It is not transitive and it is

Re: DIP1000: Scoped Pointers

On 08/17/2016 10:53 AM, Mike wrote: > On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote: >> >>> If DIP1000 is implemented, it will change that behavior, so the >>> allocation will instead be on the GC heap, but the compiler will do some >>> flow-control analysis to prevent

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 07:53:49 UTC, Mike wrote: Got it! Thank you! But it still appears that what's illustrated on the deprecations page is not being deprecated. Mike I imagine that will change if/when DIP1000 is accepted.

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote: If DIP1000 is implemented, it will change that behavior, so the allocation will instead be on the GC heap, but the compiler will do some flow-control analysis to prevent escaping references. Is that right? Mike Not

Re: DIP1000: Scoped Pointers

On Wed, Aug 17, 2016 at 9:04 AM, Mike via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > > > Or perhaps DIP1000 changes the current behavior of the `scope` storage > class. > > My understanding is that the `scope` storage class currently allocates a > class on the stack

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 07:04:26 UTC, Mike wrote: Or perhaps DIP1000 changes the current behavior of the `scope` storage class. My understanding is that the `scope` storage class currently allocates a class on the stack (though its usage for this purpose is deprecated in favor of

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 06:44:41 UTC, Mike wrote: On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire wrote: Basically DIP1000 makes it so that: void main() { A obj; { scope A a = new A(1); obj = a; } assert(obj.x == 1); // fails, 'a' has been

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire wrote: Basically DIP1000 makes it so that: void main() { A obj; { scope A a = new A(1); obj = a; } assert(obj.x == 1); // fails, 'a' has been destroyed } Will not compile. Ok, that makes sense. But

Re: DIP1000: Scoped Pointers

On 17 Aug 2016 04:00, "Mike via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote: > >>> Can you please clarify the current implementation `scope`, and what DIP1000 >>> proposes to change with respect to the

Re: DIP1000: Scoped Pointers

On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote: Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with respect to the current implementation? It just adds to the existing compiler implementation of 'scope'. It has nothing to do

Re: DIP1000: Scoped Pointers

On 8/16/2016 6:01 PM, H. S. Teoh via Digitalmars-d-announce wrote: On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via Digitalmars-d-announce wrote: On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: You need to add one more level of indirection for things to start going complicated.

Re: DIP1000: Scoped Pointers

On 8/16/2016 5:31 PM, Mike wrote: On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote: On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes. Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with

Re: DIP1000: Scoped Pointers

On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via Digitalmars-d-announce wrote: > On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: > > You need to add one more level of indirection for things to start > > going complicated. > > Presumably scope is transitive, so things shouldn't get

Re: DIP1000: Scoped Pointers

On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: > You need to add one more level of indirection for things to start going > complicated. Presumably scope is transitive, so things shouldn't get horribly complex.

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote: On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes. Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with respect to the current

Re: DIP1000: Scoped Pointers

On 8/16/2016 11:25 AM, Meta wrote: What about this? struct Rnd { int* state; } void test() { scope rnd = new Rnd(); Rnd rnd2 = *rnd; saveGlobalState(rnd2); } 'state' is set to null by 'new Rnd()', and so no pointers escape.

Re: DIP1000: Scoped Pointers

On 16 Aug 2016 21:01, "Dicebot via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote: >> >> On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote: >>> >>> What about this? >>> >>> struct Rnd >>> { >>> int*

Re: DIP1000: Scoped Pointers

On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote: On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote: What about this? struct Rnd { int* state; } void test() { scope rnd = new Rnd(); Rnd rnd2 = *rnd; saveGlobalState(rnd2); } Same as far as I understand, because

Re: DIP1000: Scoped Pointers

On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote: What about this? struct Rnd { int* state; } void test() { scope rnd = new Rnd(); Rnd rnd2 = *rnd; saveGlobalState(rnd2); } Same as far as I understand, because "from a lifetime analysis viewpoint, a struct is

Re: DIP1000: Scoped Pointers

On Tuesday, 16 August 2016 at 16:34:05 UTC, Dicebot wrote: On 08/16/2016 07:26 PM, Patrick Schluter wrote: What happens in that case ? void test() { scope rnd = new Rnd; // reference semantic and stack allocated Rnd rnd2; rnd2 = rnd;

Re: DIP1000: Scoped Pointers

On 08/16/2016 07:26 PM, Patrick Schluter wrote: > What happens in that case ? > > void test() { > scope rnd = new Rnd; // reference semantic and stack allocated > Rnd rnd2; > rnd2 = rnd; > some_sneaky_function_that_saves_global_state(rnd); > } > > or is that not even possible ? (sorry

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 21:25:22 UTC, Walter Bright wrote: On 8/15/2016 6:54 AM, Rory McGuire via Digitalmars-d-announce wrote: okay nice, so that code would not compile but code such as: void test() { scope rnd = new Rnd; // reference semantic and stack allocated auto rnd2 = rnd;

Re: DIP1000: Scoped Pointers

On 8/15/2016 6:54 AM, Rory McGuire via Digitalmars-d-announce wrote: okay nice, so that code would not compile but code such as: void test() { scope rnd = new Rnd; // reference semantic and stack allocated auto rnd2 = rnd; some_sneaky_function_that_saves_global_state(rnd); } would still

Re: DIP1000: Scoped Pointers

On Mon, Aug 15, 2016 at 4:05 PM, Dicebot via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote: > > okay nice, so that code would not compile but code such as: > > void test() { > > scope rnd = new Rnd;

Re: DIP1000: Scoped Pointers

On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote: > okay nice, so that code would not compile but code such as: > void test() { > scope rnd = new Rnd; // reference semantic and stack allocated > auto rnd2 = rnd; > some_sneaky_function_that_saves_global_state(rnd); > }

Re: DIP1000: Scoped Pointers

On Mon, Aug 15, 2016 at 2:49 PM, Dicebot via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote: > > scope rnd = new Rnd; // reference semantic and stack allocated > > auto rnd2 = rnd; > > > > rnd.i = 2; >

Re: DIP1000: Scoped Pointers

On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote: > scope rnd = new Rnd; // reference semantic and stack allocated > auto rnd2 = rnd; > > rnd.i = 2; > assert(rnd2.i == 2); > return rnd2; Point is that that would become illegal if DIP1000 is implemented thus giving scope

Re: DIP1000: Scoped Pointers

On Mon, Aug 15, 2016 at 1:57 PM, ZombineDev via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Monday, 15 August 2016 at 10:27:00 UTC, Dicebot wrote: > >> On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote: >> >>> When was it deprecated? I use it a lot and DMD

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 10:27:00 UTC, Dicebot wrote: On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote: When was it deprecated? I use it a lot and DMD 2.071.1 gives no warning. It was planned for removal because it was very un-@safe (no escaping checks whatsoever) and as such was

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote: When was it deprecated? I use it a lot and DMD 2.071.1 gives no warning. It was planned for removal because it was very un-@safe (no escaping checks whatsoever) and as such was not better than library implementation. Quite likely with

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote: On Monday, 15 August 2016 at 07:10:00 UTC, ZombineDev wrote: On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton Wakeling wrote: On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote: Isn't it what a scoped class is

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 07:10:00 UTC, ZombineDev wrote: On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton Wakeling wrote: On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote: Isn't it what a scoped class is supposed to provide? class Rnd {} void foo() { scope

Re: DIP1000: Scoped Pointers

On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton Wakeling wrote: On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote: Isn't it what a scoped class is supposed to provide? class Rnd {} void foo() { scope rnd = new Rnd; // reference semantic and stack allocated }

Re: DIP1000: Scoped Pointers

On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes.

Re: DIP1000: Scoped Pointers

On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote: Isn't it what a scoped class is supposed to provide? class Rnd {} void foo() { scope rnd = new Rnd; // reference semantic and stack allocated } Does that actually work in D2? I thought it was a D1-only thing.

Re: DIP1000: Scoped Pointers

On Saturday, 13 August 2016 at 20:50:53 UTC, Joseph Rushton Wakeling wrote: The TL;DR here is that I'm concerned about having a solution for random number generators and random algorithms that (i) allows them to be stack-allocated, (ii) ensures that their internal state is not accidentally

Re: DIP1000: Scoped Pointers

On 8/13/2016 1:50 PM, Joseph Rushton Wakeling wrote: Sure, but doesn't the envisioned DIP create the circumstances in which it could also be permitted in @safe code where the compiler can guarantee that the pointer's lifetime will not outlive the data referred to? The whole point of ref is

Re: DIP1000: Scoped Pointers

On Saturday, 13 August 2016 at 19:51:07 UTC, Walter Bright wrote: On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote: On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote: Taking the address of a ref variable has not been allowed in @safe code for a long time. Which is

Re: DIP1000: Scoped Pointers

On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote: On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote: Taking the address of a ref variable has not been allowed in @safe code for a long time. Which is understandable given things as they are, but which could probably be relaxed

Re: DIP1000: Scoped Pointers

On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote: Taking the address of a ref variable has not been allowed in @safe code for a long time. Which is understandable given things as they are, but which could probably be relaxed given good scope/lifetime analysis by the

Re: DIP1000: Scoped Pointers

On 8/13/2016 1:13 AM, Joseph Rushton Wakeling wrote: On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote: That's just what this DIP addresses. struct MyWrapperStruct (T) { private T* data; public this (ref T input) { this.data = //

Re: DIP1000: Scoped Pointers

On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote: That's just what this DIP addresses. struct MyWrapperStruct (T) { private T* data; public this (ref T input) { this.data = // error: not allowed to take address of ref variable

Re: DIP1000: Scoped Pointers

On 8/12/2016 1:08 PM, Timon Gehr wrote: On 12.08.2016 21:39, Walter Bright wrote: On 8/12/2016 5:33 AM, Nordlöw wrote: If this is successfully implemented, what will D not be able to do, that Rust can/will? Have ownership semantics for pointers in more complex data structures. In D you'll

Re: DIP1000: Scoped Pointers

On 8/12/2016 5:24 AM, Nordlöw wrote: 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!)

Re: DIP1000: Scoped Pointers

On 8/12/2016 5:33 AM, Nordlöw wrote: If this is successfully implemented, what will D not be able to do, that Rust can/will? Have ownership semantics for pointers in more complex data structures. In D you'll have to do such with ref counted objects. On the other hand, D code can reference

Re: DIP1000: Scoped Pointers

On 11.08.2016 09:48, Walter Bright wrote: 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 What are some of those things?

Re: DIP1000: Scoped Pointers

On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton Wakeling wrote: I'm not sure I follow. I'm looking for the ability to guarantee that a pointer to a stack-allocated entity will not go out of scope ... more precisely, that the pointer will not become invalid because the data it

Re: DIP1000: Scoped Pointers

On Friday, 12 August 2016 at 12:01:41 UTC, Walter Bright wrote: On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote: On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or

Re: DIP1000: Scoped Pointers

On Thursday, 11 August 2016 at 07:48:18 UTC, Walter Bright wrote: 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. If this is

Re: DIP1000: Scoped Pointers

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. Thanks for all the work. One

Re: DIP1000: Scoped Pointers

On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote: On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or 'return scope', where their usage will be limited to the expression

Re: DIP1000: Scoped Pointers

On Thursday, 11 August 2016 at 22:03:02 UTC, Walter Bright wrote: On 8/11/2016 6:38 AM, Sönke Ludwig wrote: 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

Re: DIP1000: Scoped Pointers

On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or 'return scope', where their usage will be limited to the expression they appear in. I want to make sure we have the

Re: DIP1000: Scoped Pointers

On 8/11/2016 12:59 PM, Joseph Rushton Wakeling wrote: 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: The scheme does not implement borrowing. References to internal data should be returned via 'return

Re: DIP1000: Scoped Pointers

On 8/11/2016 6:38 AM, Sönke Ludwig wrote: 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'

Re: DIP1000: Scoped Pointers

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 (...) The wording is unclear in the section "Implicit Conversion of Function Pointers and Delegates". It says "scope can be added to parameters, but not removed." The

Re: DIP1000: Scoped Pointers

On Wed, Aug 10, 2016 at 08:35:23PM +, Dicebot via Digitalmars-d-announce 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. > >

Re: DIP1000: Scoped Pointers

On Thursday, 11 August 2016 at 19:59:22 UTC, Joseph Rushton Wakeling wrote: 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)?

Re: DIP1000: Scoped Pointers

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

Re: DIP1000: Scoped Pointers

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'

Re: DIP1000: Scoped Pointers

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.

Re: DIP1000: Scoped Pointers

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

Re: DIP1000: Scoped Pointers

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 wrote: > On 11/08/2016 8:35 AM, Dicebot wrote: > >> The first DIP has just

Re: DIP1000: Scoped Pointers

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

Re: DIP1000: Scoped Pointers

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

Re: DIP1000: Scoped Pointers

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

DIP1000: Scoped Pointers

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