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