http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 29 December 2014 at 14:13, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

Okay, that's an interesting perspective. I'm not sure I'm feeling it,
but I'll see how it sits overnight :)
The problem is that inout is clearly a type modifier; it resolves to
const, or immutable... adding additional conceptual baggage that's not
type-related seems problematic. Some non-type part of it's meaning
will be lost (or incorrectly transferred) in templates?


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

It feels like a problem for 'scope' to me.


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

Well, the case where something should be (or already is) inout, but
it's not intended for it to be safe to return from the function. It
remains unsafe, even though we've specified the magic special case
that tells the compiler it's okay.


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

A terrible decision if you ask me. I really prefer to see the parens
present on type modifiers, since they affect the 'layering' of type
modifiers, and also distinguish them from storage classes.

const int *: is it const(int)*, or const(int*)?
What about when layers are deeper: const(int*)[]?
You can produce any number of unclear scenarios of this kind.

or:
  void eg(ref const S x)
  {
    f(x);
  }

  void f(T)(T x) // <- x is const, but not ref? why did some
attributes disappear but not others?
  {
  }

I like the clear visual distinction so people aren't wondering what happened.


>> I'd also like to know how this will help DIP69?
>
>
> Just takes the entire ref handling out of the equation.

Then DIP69 seems to lose all purpose?
The whole thing is about safer indirections.


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

I was giving a context with vibe.d, but I think they key take-aways were:

First-impressions; in our case, that was Windows environment setup,
but the point should be taken generally, and that includes IDE
integration. The effect of a poor experience here is eroding user
confidence before they've even written a single line of code.
Expectations are high, other programming communities are nailing this.

Debugging was the biggest issue, and turned out to be the dealbreaker.
We couldn't get behind something that we were unable to fix if we have
to. (I say 'we', meaning the general office perception, and that
perception was definitely coloured by the prior experiences re;
first-impressions)

Also documentation received a lot of criticism from the new-users,
although I didn't identify it as a deal-breaker. I experienced this
same frustration myself years ago. It's easy to address, I just wanted
to demonstrate importance.


Trust me that these guys were REALLY excited to try out D when we got
started. But their confidence was eroded very quickly by these factors
in aggregate.
I think D will get another shot with this lot at some later stage when
demonstrable progress has been made.


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

I've already argued against this assertion, because it got kind of
aggressive. I was just reporting a case-study.
People can do whatever they want, I'm only trying to reaffirm the
reality of the importance of the same stuff that I've been going on
about since the day I showed up here.
There has been really great improvement, and we're getting awfully
close to the line, but we're still just a little way short.

It's a shame, because that boring stuff that nobody is interested in
working on is inhibiting people from getting amongst the cool stuff
that's going on here.


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

Right, this will be interesting. First I've heard of it.
I'm sure corporate users would put their money on the table if they
were purchasing some sort of support package, ie, greater confidence
in the tooling and infrastructure.
Especially in Windows-land, we're accustomed to paying for polished experiences.


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

I only make the distinction because years of experience to date has
demonstrated clearly that the storage class concept is the source of
most of the awkward language problems I encounter.
Focusing on the current high-level goal will only lead to
context-specific patches (ie, further edge cases), and in this case
where I can clearly see the root of a series of problems spanning
years, it seems like the wrong thing to do.
There is time to approach a problem as you say, but I don't think this
is one of them. That said, if there is a vision presented that keeps
storage class and fixes the problems, I'm all for it, but nobody's
presented one, I can't envision one, and I've thought about it a lot.
The solution practically implies building a system of tools to
manipulate storage classes that parallels the existing system for
types... I don't see the point.

Surely it's not a bad thing to explore the thought that 'storage
class' may have actually been a mistake? There's room for retrospect.
You don't need to defend a bad idea when it's proven to be a problem.

ref is basically a broken design, it works in only the simplest of use
cases, and otherwise adds unwieldy complication to any more complex
language structures. The primary reason for that is because
semantically, it lives external to the 'meat' of the D language.
I suspect its original design is the direct result of the kind of
approach to the problem you're asking me to take; "user wants to pass
by ref, we'll try something that satisfies exactly the target use
case, and tries to isolate itself from any language side-effects", but
I think that attempt to isolate itself from cascading side-effects is
precisely the reason for all of it's awkward side-effects.
Perhaps there will be awkward side-effects either way? ...in this case
though, we have no tools to mitigate them manually. Code duplication
and text mixin are the only effective tools we have to manage ref
problems.