August 11, 2016
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)?

Some context for my interest here:
https://forum.dlang.org/post/jvgguodpfuaicsvplcgp@forum.dlang.org

TL;DR is, I think that this functionality potentially unlocks a solution for how to implement really effective and safe solutions for range-based random number functionality (both memory-safe and statistically safe).
August 11, 2016
On Wed, Aug 10, 2016 at 08:35:23PM +0000, 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.
> 
> 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
[...]

I found some unclear parts of the proposal:

- Under "examples for each rule", in fun2(), the comment says "OK, b is
  a regular int*". However, at this point b isn't declared yet, and the
  next line which declares b, declares it as int, not int*. So what is
  the comment supposed to say?

- Under "A few more examples combining the rules", in abc(), 3rd line,
  the comment says "Error, rule 5". But there is no rule 5!


T

-- 
I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.  In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
August 11, 2016
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 trouble is that the word "added" can be understood in two opposite ways.

When you assign an address to a pointer variable, you can say that:

- you are assigning a new runtime value, so you are adding scope of parameter of the right hand side to the otherwise unscoped parameter of the left hand side, e.g.

alias T function(T) fp_t;
T bar(scope T);
fp_t   fp = &bar;   // Ok

- you are converting to a new variable, so you are adding scope of param of the left hand side to an otherwise unscoped param of the right hand side, e.g.

alias T function(scope T) fps_t;
T foo(T);
fps_t  fp = &foo;   // Error


Half-jokingly, I think its good to recognize that there is an ambiguity before multiple authors implement things with different assumptions and have a month-long discussion on github. :)

More seriously, this wording may make its way to documentation after the design is implemented.

If wording is fixed, I suggest also checking if all examples are correct.
August 11, 2016
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' 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 adds a fair amount of complication I haven't worked through.

August 11, 2016
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 ref' or 'return scope', where their usage will be limited to the expression they appear in.

August 12, 2016
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 same understanding here: the use-case I'm interested in is a data structure that needs to hold a reference to data it does not own -- where, obviously, the lifetime of the data structure cannot outlive the lifetime of the data it references.

Surely this scope proposal ought to address that use-case?
August 12, 2016
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 `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 adds a fair amount of complication I haven't worked through.

It can probably be done by lowering:

    scope T* payload;

Is conceptually:

    private T* payload_;
    @property scope T* payload() scope {
        return payload_;
    }
August 12, 2016
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 they appear in.
>
> I want to make sure we have the same understanding here: the use-case I'm
> interested in is a data structure that needs to hold a reference to data it does
> not own -- where, obviously, the lifetime of the data structure cannot outlive
> the lifetime of the data it references.
>
> Surely this scope proposal ought to address that use-case?

Using ref counted objects should deal with that nicely.
August 12, 2016
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 remarks. I guess `RefCountedSlice` should infer access permissions of `payload` and `count` to allow

    RefCountedSlice!(const(T))

right? Is that beyond the scope of the DIP?
August 12, 2016
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 successfully implemented, what will D not be able to do, that Rust can/will?