On 12/28/2014 1:33 PM, Walter Bright wrote:
> 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.
>

Also, inout on parameters will be inferred for templates, and most ranges are templates.

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 tried to understand the previous DIP but it was difficult. I like how this new version explains what is being added and why. The examples really help. I still need some time to understand all the ins and outs of the concept but it has a nice ring of clarity.

Nice work and thanks!

Joseph

On 12/28/14 4:32 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> 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.

Got it - could you please add what would be a satisfactory 'splanation? Thanks! -- Andrei

On 12/28/14 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?

Not even those for the most part. The archetypal higher order range:

struct Wrapper(R)
{
    private R payload;
    ref ElementType!R front() {
        return payload.front;
    }
    ...
}

If R.front() returns a ref T, that's all Wrapper needs to know - the call just works. That would be the case if e.g. R is T[].

If R.front() is inout-qualified, indeed Wrapper needs to propagate that. In this case, however, deduction can take care of it; Walter ensures me that deduction of inout is cheap and relatively easy. I need to add a section on it to the DIP.

For non-templates, inout would need to be added if a range that owns its elements is to be wrapped. But generally ranges don't own stuff (i.e. they can disappear and stuff is still there). Containers own stuff.


Andrei

On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> 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 could generally understand the intent, but I don't really understand
the connection between ref and inout.
They seem like unrelated things. I feel like conflating them could
only lead to unexpected problem cases when the concepts coincide
naturally, but the intent wasn't this assigned special case.
I wonder if we're just narrowing the window of edge cases, and
possibly into a slightly more awkward position for later fixes?

I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
inout look like the type modifier that it is, rather than a storage
class, which it isn't.
That distinction made me start second-guessing my assumptions
throughout, and reduced my confidence in my understanding of the
proposal.

I'd also like to know how this will help DIP69? I can't imagine how this could help DIP69 address the basic problems I was concerned with (ie, distilling towards; 'storage class' is practically a bad design for D, and my numerous rants and walls of text that follow).

On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote:
> On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> 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 could generally understand the intent, but I don't really understand
> the connection between ref and inout.
> They seem like unrelated things. I feel like conflating them could
> only lead to unexpected problem cases when the concepts coincide
> naturally, but the intent wasn't this assigned special case.
> I wonder if we're just narrowing the window of edge cases, and
> possibly into a slightly more awkward position for later fixes?

Walter's reasoning was: we have inout for propagating qualifiers from a parameter ("this" is also a parameter) to the output, so we can use it for propagating aliasing information as well.

One idea we discussed was to use "return" like this:

ref int fun(return ref int x); // may return x

Walter didn't like it. I'm somewhat neutral.

Any examples of cases when having inout do both would cause trouble?

> I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
> inout look like the type modifier that it is, rather than a storage
> class, which it isn't.
> That distinction made me start second-guessing my assumptions
> throughout, and reduced my confidence in my understanding of the
> proposal.

When applied to a parameter, the parens are redundant.

> I'd also like to know how this will help DIP69?

Just takes the entire ref handling out of the equation.

> I can't imagine how
> this could help DIP69 address the basic problems I was concerned with
> (ie, distilling towards; 'storage class' is practically a bad design
> for D, and my numerous rants and walls of text that follow).

I did want to say something about this. I've given a close read to the "Lost a new commercial user this week" thread, through and through. It seems I've identified a problem that belongs to us. ("Us" is a vacuous term meaning "the leaders of the D community").

My initial read of your complaint went like this: it's about Windows (I don't even have an installation), it's about vibe.d (haven't used it yet), and it's also discussing documentation (which is something we can indeed improve and I know how to). So a large part of the problem wasn't even mine to work on.

Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time.

Then I figured we must take ownership of D issues. Your initial post was pure and simple user feedback - a knowledgeable and well-informed and well-meaning user but nevertheless a user who is not quite willing to roll sleeves up and proceed with adding work. If we consider ourselves a free-wheeling grassroots tribe, best we can do invite you to do the work and review and merge it in (or snicker at you if you're not up for it). If, on the other hand, we want to be a real organization, we must take the feedback and own it.

A simple simile: say you mention to the manager of a grocery store that they should have more organic fruit, and mention anecdotes of potential customers shunning the store because it doesn't. If the store is a cooperative of folks selling stuff they grow on their own, the manager might invite you to join in with your produce. If, on the other hand, the store is an established supermarket, they'd do good to take your suggestion seriously.

We're in the "cooperative" stage of D, and we need to move toward the "established organization" stage. We should start transitioning to that next year; part of it is I plan to look seriously at the non-profit organization angle.

There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks.


Andrei

On 12/28/2014 6:29 PM, Andrei Alexandrescu wrote:
> If R.front() is inout-qualified, indeed Wrapper needs to propagate that. In this
> case, however, deduction can take care of it; Walter ensures me that deduction
> of inout is cheap and relatively easy. I need to add a section on it to the DIP.

Here's how the deduction works. I presume the existence of a check to see if a ref parameter is being returned by ref. If deduction is not being done, an error message is issued:

    error: 'ref' parameter 'x' is being turned by ref, needs to be 'inout ref'

If deduction is being done, the error message is not issued, but the parameter is marked as 'inout'.

On 12/28/2014 5:57 PM, Joseph Cassman wrote:
> I tried to understand the previous DIP but it was difficult. I like how this new
> version explains what is being added and why. The examples really help. I still
> need some time to understand all the ins and outs of the concept but it has a
> nice ring of clarity.

Phew!

> Nice work and thanks!

Thank you.

On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
> "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.

So are you saying that such code will require the following if this DIP is implemented?

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

The idea is sound but that will be incredibly tedious to type out. I know that Walter wants to infer inout for templates (a good idea), but at some point or another somebody is going to have to type that out for a regular function. Since scope is up in the air right now, could it be redefined to mean `auto ref inout`? It's a bit humourous; `in` would then mean `const auto ref inout`.

Also, I guess this DIP implies that `auto ref` should work for non-templated functions as well. That seems pretty good, but the rvalue ref problem still hasn't been solved, and it's hard to say whether DIP25 would help or hurt prospects for that.

On 12/29/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> We're in the "cooperative" stage of D, and we need to move toward the "established organization" stage.

Unrelated to this grander idea I really liked the recent Rust blog post: http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062

We could consider writing these styles of posts for major changes (like DIP25). We already have the changelog that documents everything /after/ a release, but having a page where we announce upcoming changes for the general population to read would be nice.

Once we agree on all aspects on DIP25, perhaps we could write a page about it and put it up on dlang.org/news.html or somewhere. What do you think?