www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - Reply to Walter Bright

reply Olivier FAURE <olivier.faure epitech.eu> writes:
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.
Jan 29 2017
next sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Sunday, 29 January 2017 at 11:20:48 UTC, Olivier FAURE wrote:
 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?
Whoops. That is a typo. I meant 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); }
Jan 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2017 3:24 AM, Olivier FAURE wrote:
 Whoops. That is a typo. I meant
It's best to post compilable code fragments. This code compiles with -dip1000: struct Container { int* ptr; } ref Container store(ref return scope Container c, return scope int* ptr) { c.ptr = ptr; return c; } void foobar() { Container c; scope int* ptr; scope Container c2 = store(c, ptr); }
Jan 29 2017
parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Sunday, 29 January 2017 at 11:45:30 UTC, Walter Bright wrote:
 On 1/29/2017 3:24 AM, Olivier FAURE wrote:
 It's best to post compilable code fragments. This code compiles 
 with -dip1000:
It shouldn't. This is one of the 'gotcha's that I mentioned earlier. struct Container { int* ptr; } ref Container store(ref return scope Container c, return scope int* ptr) safe { c.ptr = ptr; return c; } Container* foobar() safe { Container* c = new Container; int x = 42; scope int* ptr = &x; scope Container c2 = store(*c, ptr); return c; } void main() safe { import std.stdio; import std.conv; int x = *foobar().ptr; // invalid write } This code should not compile, and having a safe opaque 'store' function is not possible with 'return scope' alone unless you use the functional programming idiom of returning a new object instead of mutating objects passed by reference.
Jan 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2017 4:10 AM, Olivier FAURE wrote:
 On Sunday, 29 January 2017 at 11:45:30 UTC, Walter Bright wrote:
 On 1/29/2017 3:24 AM, Olivier FAURE wrote:
 It's best to post compilable code fragments. This code compiles with -dip1000:
It shouldn't. This is one of the 'gotcha's that I mentioned earlier. struct Container { int* ptr; } ref Container store(ref return scope Container c, return scope int* ptr) safe { c.ptr = ptr; // Error: scope variable ptr assigned to c with longer lifetime return c; }
I made a mistake, I had forgotten to add safe to store(). With that, the example I posted does not compile, and neither does the expanded one here, with the error message I added in.
Jan 29 2017
parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Sunday, 29 January 2017 at 22:13:03 UTC, Walter Bright wrote:
 I made a mistake, I had forgotten to add  safe to store(). With 
 that, the example I posted does not compile, and neither does 
 the expanded one here, with the error message I added in.
It compiles on my version (2.073.0), but whatever. I don't care about whether or not it compiles, and I feel you're seriously missing my point. I ask you this sincerely: why do you think I brought up the "store" example in this thread?
Jan 30 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2017 3:20 AM, Olivier FAURE wrote:
 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
This stuff has been around for a long time, so has -dip1000. There was recent other thread on it in this n.g., see the thread entitled "DIP1000 discussion and testing". D desperately needs a way to guarantee safe code. I'm interested only in getting a workable scheme implemented, not putting things off for another year of nothing happening. Nobody is being shut down for proposing or discussing alternatives. Anyone who wants to, please feel free. That's what this n.g. is for.
Jan 29 2017
parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Sunday, 29 January 2017 at 12:12:04 UTC, Walter Bright wrote:
 This stuff has been around for a long time, so has -dip1000. 
 There was recent other thread on it in this n.g., see the 
 thread entitled "DIP1000 discussion and testing".

 D desperately needs a way to guarantee safe code. I'm 
 interested only in getting a workable scheme implemented, not 
 putting things off for another year of nothing happening.

 Nobody is being shut down for proposing or discussing 
 alternatives. Anyone who wants to, please feel free. That's 
 what this n.g. is for.
Alright, this is becoming legitimately infuriating. Earlier I posted:
 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.
Look, I'm saying that you're either dismissing my points or ignoring them completely. You read that. Yet you didn't even comment on it. This feels incredibly disrespectful. Like, not responding to my remarks about D is one thing, but not responding to my remark about how I'd like to be treated seriously feels like a superior level of disrespect. I'm trying to tell you that I want to be treated seriously, and you act like you haven't heard anything. You don't have to agree with me at all, but at least **ACKNOWLEDGE WHAT I'm SAYING, DAMMIT**.
 Nobody is being shut down for proposing or discussing 
 alternatives. Anyone who wants to, please feel free. That's 
 what this n.g. is for.
There's a difference between "not shutting anyone down" and "not encouraging things to go in one specific direction at the detriment of others". You're pushing dip1000; it's being implemented right now, and you're making it clear that it's going to happen no matter what other people think. That means that any non-dip1000 proposal is going to face an uphill battle, because it's has to go against a proposal that's already being there. You didn't explicitly shut down MS's proposal. You did so implicitly, and unilaterally.
Jan 30 2017