[Dlang-internal] Reply to Walter Bright
Olivier FAURE via Dlang-internal
dlang-internal at puremagic.com
Sun Jan 29 03:20:48 PST 2017
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.
More information about the Dlang-internal
mailing list