Walter and I have been working on revamping DIP25, which focuses on tightening the screws of ref. This should then simplify DIP69 significantly.

Please comment: http://wiki.dlang.org/DIP25


Thanks,

Andrei

On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu wrote:
> Please comment: http://wiki.dlang.org/DIP25

This seems like it may be painful (in terms of breaking existing code):

"Member functions of structs must qualify this with inout if they want to return a result by ref that won't outlive this."

This breaks all ranges that return ref front, no? (assuming they aren't qualified inout, which appears to be the case in the majority of ranges in std.algorithm/range).

Clarification: how does this DIP play with auto ref returns? Infer non-ref if not qualified inout?

auto ref foo(ref int x) { return x; }  // non-ref due to lack of inout on x?

On 28/12/14 04:09, Andrei Alexandrescu via Digitalmars-d wrote:
> Walter and I have been working on revamping DIP25, which focuses on tightening
> the screws of ref. This should then simplify DIP69 significantly.
>
> Please comment: http://wiki.dlang.org/DIP25

How will that interact with designs like the singleton used in e.g. std.random.rndGen:

    @property ref Random rndGen() @safe
    {
        import std.algorithm : map, repeat;

        static Random result;
        static bool initialized;
        if (!initialized)
        {
            static if(isSeedable!(Random, typeof(map!((a) => unpredictableSeed)(repeat(0)))))
                result.seed(map!((a) => unpredictableSeed)(repeat(0)));
            else
                result = Random(unpredictableSeed);
            initialized = true;
        }
        return result;
    }

... will it be as simple as adding an 'inout' qualifier to the method and/or return type?  In any case I think it's a use-case worth adding to the example list.

On 28/12/14 13:23, Joseph Rushton Wakeling via Digitalmars-d wrote:
> ... will it be as simple as adding an 'inout' qualifier to the method and/or
> return type?  In any case I think it's a use-case worth adding to the example list.

Ack, I missed it hidden away in the second-to-last example (the one at the end of the 'Enhancing inout' section), where there's a static int b that is returned via ref, with no qualifiers required.  Still think it might be worth highlighting separately how this DIP works with that singleton pattern.

On 12/28/14 2:13 AM, Peter Alexander wrote:
> On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu wrote:
>> Please comment: http://wiki.dlang.org/DIP25
>
> This seems like it may be painful (in terms of breaking existing code):
>
> "Member functions of structs must qualify this with inout if they want
> to return a result by ref that won't outlive this."
>
> This breaks all ranges that return ref front, no? (assuming they aren't
> qualified inout, which appears to be the case in the majority of ranges
> in std.algorithm/range).

Very little breakage I can think of. Ranges usually don't own their payload.

> Clarification: how does this DIP play with auto ref returns? Infer
> non-ref if not qualified inout?
>
> auto ref foo(ref int x) { return x; }  // non-ref due to lack of inout
> on x?

"auto" has no meaning there. It does here:

auto ref foo(auto ref int x) { return x; }

This wouldn't compile anymore - inout is needed for x as well.


Andrei

On 12/28/14 4:23 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 28/12/14 04:09, Andrei Alexandrescu via Digitalmars-d wrote:
>> Walter and I have been working on revamping DIP25, which focuses on
>> tightening
>> the screws of ref. This should then simplify DIP69 significantly.
>>
>> Please comment: http://wiki.dlang.org/DIP25
>
> How will that interact with designs like the singleton used in e.g.
> std.random.rndGen:
>
>      @property ref Random rndGen() @safe
>      {
>          import std.algorithm : map, repeat;
>
>          static Random result;
>          ...
>          return result;
>      }
>
> ... will it be as simple as adding an 'inout' qualifier to the method
> and/or return type?  In any case I think it's a use-case worth adding to
> the example list.

No need to add anything here because returning a static is still fine. -- Andrei

On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
> Very little breakage I can think of. Ranges usually don't own their payload.

I'm thinking more about higher order ranges, e.g. take, filter, cycle, retro; over a mutable range with ref front. Even if the underlying range (e.g. an array) has the inout, the higher order range will need the inout as well, so that it is propagated, no?


>> auto ref foo(ref int x) { return x; }  // non-ref due to lack of inout
>> on x?
>
> "auto" has no meaning there. It does here:
>
> auto ref foo(auto ref int x) { return x; }
>
> This wouldn't compile anymore - inout is needed for x as well.

Ah, yep. That's what I meant :-)  Thanks for the clarification.

On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:
> Walter and I have been working on revamping DIP25, which focuses on tightening the screws of ref. This should then simplify DIP69 significantly.
>
> Please comment: http://wiki.dlang.org/DIP25
>
>
> Thanks,
>
> Andrei

I like the simplicity of it. It's a lot easier to understand than
the previous version. The breaking change is easy to identify and
fix and could actually reveal bugs.

+1

I still have to read through DIP 69 to see how this works with
that but I think this DIP would be a good addition on its own.

On 12/28/2014 12:45 PM, Brad Anderson wrote:
> On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
> wrote:
>> Walter and I have been working on revamping DIP25, which focuses on tightening
>> the screws of ref. This should then simplify DIP69 significantly.
>>
>> Please comment: http://wiki.dlang.org/DIP25
>>
>>
>> Thanks,
>>
>> Andrei
>
> I like the simplicity of it. It's a lot easier to understand than
> the previous version. The breaking change is easy to identify and
> fix and could actually reveal bugs.
>
> +1
>
> I still have to read through DIP 69 to see how this works with
> that but I think this DIP would be a good addition on its own.

Although I believe DIP69 is technically sound, it was abundantly clear from the thread about it that almost nobody understood it. It was too complicated and unintuitive. Andrei convinced me we had to go back to the drawing board.

DIP25 still needs to address things like overloading and inheritance, but I think we can just swipe that from DIP69.

On 12/28/2014 12:04 PM, Peter Alexander wrote:
> On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
>> Very little breakage I can think of. Ranges usually don't own their payload.
>
> I'm thinking more about higher order ranges, e.g. take, filter, cycle, retro;
> over a mutable range with ref front. Even if the underlying range (e.g. an
> array) has the inout, the higher order range will need the inout as well, so
> that it is propagated, no?

inout is not transitive, so a ref on the container doesn't apply to a ref on the contents if there's another level of indirection in there.