[Dlang-internal] Reply to Walter Bright

[Olivier FAURE via Dlang-internal]

Alright, this was getting pretty off-topic for the Announce 
thread, so I'm continuing here. This is the continuation of the 
discussion started here:

http://forum.dlang.org/post/o6jdm0$30d9$1@digitalmars.com

For reference, Marc Schütz's proposal is here:

http://wiki.dlang.org/User:Schuetzm/scope

And dip1000's overview is here:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

On Sunday, 29 January 2017 at 00:40:47 UTC, Walter Bright wrote:
>> What would the syntax be?
>
>     c.ptr = ptr;
>
> You can also do:
>
>     ref Container store(ref return scope c, return scope int* 
> ptr);

Wait, then does that mean:

     ref Container store(ref return scope c, return scope int* ptr)
     {
         c.ptr = ptr;
         return c;
     }

     void foobar()
     {
          Container c;
          scope int*      ptr = ...;

          scope Container c2 = ;
          store(c, ptr);
      }

...is legal? That doesn't seem right. I'm sorry if I'm 
misinterpreting you. Unless you meant that 'store' builds a new 
Container OCaml-style?

Regardless, what if 'store' is a virtual method of Container?

> Yes, the result is the "merged" scope. This issue is a known 
> (discussed previously on the n.g.) limitation. Is it a 
> significant one? I doubt it, as I have a hard time contriving a 
> realistic example. Time will tell, though.

Did you read the part where I said:

> Although it's not that important, because this particular case
> would rarely appear in actual practical code, unlike swap and 
> out parameters.

The part you addressed as unlikely to be significant was the part 
I pointed as unlikely to be significant, and it seems you kinda 
ignored the parts I think are likely to pop in real code.

(although, as your previous example showed, 'return scope' makes 
the functional code style more likely to be needed, which in 
turns make not being able to return several values with different 
semantics more likely to be a problem)

>> And having read the thread it was proposed in... I didn't see 
>> any brainstorming?
>> It seems to me that dip25 replaced Schult's proposal without 
>> transition, or
>> without debate about the merits and trade-offs of either 
>> proposition, or any
>> rationale explaining why Schultz's proposition was abandoned.
>
> The rationale is I was looking for a much simpler scheme. Even 
> -dip25 is a very simple scheme, and I have a hard time 
> convincing people to use it. What chance does a complex 
> annotation scheme have?

I understand, and this is what I saw when I researched dip1000's 
history. I'm not saying that there wasn't a rationale for going 
from MS's proposal to dip25. I'm saying that, as far as I'm 
aware, this rationale wasn't debated. As I said earlier, it seems 
to me that you saw an idea, you thought "How can I make this idea 
better?", then you made your own idea and told everyone "Hey, 
let's use this idea!", and the old idea was forgotten.

I don't think this process is a healthy way to handle major parts 
of a community-driven, FLOSS project (although you may disagree 
with other people about how community-driven this project is or 
should be).

I think there really, really, really should be (and/or should 
have been) a big brainstorming where lots of people consider 
different ideas (Rust's scheme, dip1000, MS's proposal, etc) and 
debate their respective merits.

Like, I totally get that you want a simple scheme and everything. 
But as far as I'm aware, you just made the decision on your own 
that a very simple scheme was needed, without consulting the 
community and listening to alternate ideas; and you took every 
criticism to dip25 as a hint that you needed to improve your idea 
*IN THE DIRECTION YOU HAD ALREADY CHOSEN UNILATERALLY*.

>> I'll probably have more to say on that later, but I think THIS 
>> is the major
>> point of contention. I don't feel like you've addressed my 
>> concerns, because I'm
>> pretty sure you haven't understood my concerns. You 
>> interpreted my remarks as
>> obstacles to be overcome, not as information I was trying to 
>> communicate to you.
>
> Aren't problems obstacles to be overcome? I don't really 
> understand your point. You ask me to clarify, I try to clarify. 
> You ask how can this be done, I try to answer. You say you 
> don't like the syntax, I agree and say I can't find anything 
> better. You say there's a limitation, I agree and say based on 
> my experience with it so far it is not a killer limitation.

I think it's subtle and it's hard to describe, but this is not 
how I (or anyone) want my concerns to be addressed.

> Aren't problems obstacles to be overcome?

I don't want my criticism to be considered as "problems" that 
should be solved. This ties back to what I was saying: it seems 
you think that the major reason I disagree with you is that I 
don't understand the subject well enough. Even if it's true (and 
I think by now I have demonstrated that I've done quite a bit of 
research before posting here), it's still annoying and 
counter-productive.

You said earlier

> If you've got a case, make it. If you see problems, explain.
> If you want to help, please do.

And deadalnix and pineapple reacted with frustration, because 
they thought that if they explained their reasons for not wanting 
dip1000, you would tell them that the problems they saw were 
minor or easily avoided.


ALTERNATE PROPOSAL THING

First off, I don't believe anyone dislikes dip1000 for not being 
simple or easy enough. The major complaints I've seen were:

- That you started implementing it before anyone else but you 
really understood how it works. The fact that you haven't posted 
a formal definition of 'return scope' doesn't help; I think that 
there would be much fewer people asking you about corner cases 
and implementation details if there were a formal definition.

- That it is like inout, in that the logic doesn't map elegantly 
to program logic. This is a subtle problem, and I don't have 
anywhere near the formal knowledge to explain it properly. It 
poses problems with reflection, templates and any code dealing 
directly with logic and the type system.

I think most complaints the DIP has, and most "Look at this code 
it is broken" examples people give you, come from those two 
problems.

My major complaint is that the dip is too limited. Which is why, 
again, I'd like to bring back Schult's proposal, or an equivalent 
one, for consideration.

> The rationale is I was looking for a much simpler scheme. Even 
> -dip25 is a very simple scheme, and I have a hard time 
> convincing people to use it. What chance does a complex 
> annotation scheme have?

Maybe you're right, and people would hate it too. But I'd like at 
least for it to be considered, especially since, if it's 
implemented, the 'return scope' keyword could be kept as a 
syntactic sugar for a more general system. Have you *asked* 
people about this? I mean, I've read MS's thread, and I saw a lot 
of enthusiasm there (also people discussing it's technical 
limitations and what obstacles blocked it).

Anyway, thank you for taking the time to answer me. I'm sorry to 
be as blunt and critical as I am. But, well, people are upset and 
stuff, so this needs to be addressed.