http://wiki.dlang.org/DIP25

[Andrei Alexandrescu via Digitalmars-d]

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 at 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