May 22, 2020
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> [snip]

Thank you for your reply.

How about some time before this DIP is fully in the language, a compiler flag is added that will produce warnings for when extern prototypes without explicit @safe/@trusted/@system are used? Or something like that. I have a good sense of when my own code uses extern(C), but not always other people's.
May 23, 2020
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
> With the rationale laid out clearly as it is here, I do have some responses in mind.  But before sharing them, I'd like to know whether that would be useful right now: I've no wish to just press for a re-hashing of conversations that have already been had.

No.

This wasn't the first and certainly won't be the last time we as a community have been very unhappy with how Walter conducts himself with his DIP's.

Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position.
May 22, 2020
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
> Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position.

One thing that need to be clear and for I read it was not remotely answered from Walter is why this DIP process and discussion exists if in the end like it or not it will be incorporated.

As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now.

And again why waste time with this process plus 2 rounds of discussion?

I mean just do it and tell in this announcement section about the feature.

Matheus.
May 22, 2020
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
> On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
>> Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position.
>
> One thing that need to be clear and for I read it was not remotely answered from Walter is why this DIP process and discussion exists if in the end like it or not it will be incorporated.
>
> As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now.
>
> And again why waste time with this process plus 2 rounds of discussion?
>
> I mean just do it and tell in this announcement section about the feature.
>
> Matheus.

There is no democracy. The decisions are simply made by Walter and Atila.

From my understanding, the purpose of the DIP process is to improve DIPs and find any potential flaws before a final decision ist made by the two language maintainers. However, how much of the review the maintainers take into account is their own decision.

In theory, this results in much higher quality DIPs and the chance of a DIP that actually makes it to the formal assessment stage to be accepted is a lot higher. It also seems to work quite well when the DIP author is not one of the language maintainers. From my experience, the quality of those DIPs really has gone up by a lot. There is also a lively discussion about each DIP and the authors are actively participating. It is in their own interest to do so because getting feedback and addressing it increases the quality of the proposal which in turn increases the chance of the DIP being accepted.

If the author is one the language maintainers, this doesn't seem to work that well though. There is simply less motivation for them to do all of that because in the end, they can make the decision by themselves anyways. I am not saying that the language maintainers do this on purpose, it is simply a psychological effect. And the result can be seen very clearly when comparing review threads for DIPs from the language authors with review threads for DIPs from others.

In defense of the language authors, it has to be stated that the situation has improved quite a bit over time. Examples of this are how DIP1017 was handled or the fact that Walter now gave a reasoning for his decision regarding DIP1028 (even if only after being asked to do so). But unfortunately, sometimes it still really feels like DIPs from the language maintainers and DIPs from others are handled quite differently by the maintainers.
May 22, 2020
On 22.05.20 03:22, Walter Bright wrote:
> 
> This is Obviously A Good Idea. Why would I oppose it?
> 
> 1. I've been hittin' the crack pipe again.
> 2. I was secretly convinced, but wanted to save face.
> 3. I make decisions based on consultation with my astrologer.
> 4. I am evil.

5. You are backwards-rationalizing a wrong intuition that is based on experiences that are not actually analogous. You are ignoring feedback given by many people around you because that worked out well for you in the past.

I know that you had many interactions with large groups of ignorant people who thought that you would never be able to pull off a certain thing. This is not one of those cases. I understand the appeal, but the backlash really should not encourage you to soldier on this time.

> 
> 1. Go through 200 functions in clibrary.d and determine which are @safe
> and which are @system. This is what we want them to do. We try to motivate
> this with compiler error messages. Unfortunately, this is both tedious and
> thoroughly impractical, as our poor user Will Not Know which are safe and
> which are system. We can correctly annotate core.stdc.stdio because I know
> those functions intimately. This is not true for other system C APIs, and
> even less true for some third party C library we're trying to interface to.
> 
> 2. Annotate useClibrary() as @trusted or @system. While easier,

First do 2, then, over time, do 1. If having the @safe tag and no @trusted code is important to you, aim to replace the C code with something you can automatically verify, by slowly porting it over to D.

> this causes all benefits to @safe by default to be lost. 

Absolutely not. Greenwashing causes the benefits of certification to be lost. Honesty does not. The value of @safe code is what it is because there is code that can't be @safe.

> 
> 4. Edit clibrary.d and make the first line:
> 
>      @safe:
> 
> I submit that, just like with Java, Option 4 is what people will reach for,
> nearly every time. I've had some private conversations where people admitted
> this was what they'd do. People who knew it was wrong to do that.
> ...

They should know to put @trusted instead of @safe, and the compiler should enforce it. Also, why do those people speak for everyone else? They don't speak for me.

> If it's @safe by default, and then someone chooses to annotate it with @system
> here and there, I'd feel a lot more confident about the accuracy of the code
> annotations than if it just had @safe: at the top. At least they tried.
> ...

If it has @safe:/@trusted: at the top at least you know they were aware what they were doing.
Also, what about if it has @trusted: at the top and some @system annotations here and there? Did they not try?

> What is actually accomplished with this amendment if it was implemented?
> 
> 1. Adds a funky, special case rule. It's better to have simple, easily
> understood rules than ones with special cases offering little improvement.
> ...

What about the funky special case rule that the compiler is responsible for memory safety of @safe code except in this one weird special case?

> 2. Existing, working code breaks.
> ...

Making @safe the default is bound to break code. It's bad enough that code will break. Avoiding part of that code breakage is no justification for breaking @safe.

> 3. The most likely code fixes are to just make it compile, absolutely
> nothing safety-wise is improved. The added annotations will be a fraud.
> ...

It's vastly better to have some fraudulent annotations in some projects than a fraudulent compiler compiling all projects. Do you really want to put the responsibility for the memory safety of random C libraries on the compiler developers?

> D should not encourage "greenwashing" practices like the Java
> exception specification engendered.

So your argument is that you don't want D programmers to do have to do the dirty work of greenwashing. Therefore the compiler will implicitly greenwash for them? What about the programmers who actually want to do the right thing and don't want the compiler to implicitly greenwash C libraries for them?

> The compiler cannot vet the accuracy
> of bodyless C functions, and we'll just have to live with that. The proposed
> amendment does not fix that.
> ...

@trusted is the fix.

> And so, I did not incorporate the proposed amendment to the Safe by Default
> DIP.

Which (so far) is a harmless mistake with an easy fix.
May 22, 2020
On Friday, 22 May 2020 at 13:16:50 UTC, Johannes Loher wrote:
> ... But unfortunately, sometimes it still really feels like DIPs from the language maintainers and DIPs from others are handled quite differently by the maintainers.

That's was my point about "democracy", maybe not a right word.

In fact I really think that in the end someone will need to decide (for good or bad), but it's not the first time I read about this nuances between DIPs created by maintainers and others like you said.

I think for such small community, there should be a vote system for those who are actively contributing (I am NOT in this niche by the way) to guide the language.

It would be better than a rounds of discussion without any meaning.

Matheus.

May 22, 2020
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
>
> As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now.
>
> And again why waste time with this process plus 2 rounds of discussion?
>
> I mean just do it and tell in this announcement section about the feature.
>

The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process. It's intended to elicit community feedback to enhance the DIP under review (the Feedback Threead) and to allow the airing of opinions (the Discussion Thread). All DIP authors have the freedom to incorporate suggestions into their DIP or not, and Walter and Atila make the decision to accept or reject. If you look at the history of Walter's DIPs, they *do* take the opinions into consideration even when he is the author. Several of his previous DIPs have been withdrawn or rejected.

If a popular DIP is rejected, it means neither of them were convinced by opinion to accept it. And, as in the case for this DIP, if an unpopular DIP is accepted, it means they were not persuaded by the arguments against it.

From my perspective, the process is working as intended, despite the comments to the contrary in this thread. You either convince a DIP author to modify his DIP, or you don't. You either persuade Walter and Atila to accept or reject it, or you don't.
May 22, 2020
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
> Someone has created bindings for a C library and published them on
> code.dlang.org. Because they were written prior to DIP 1028, the author assumed
> that @system was the default, and didn't bother to add explicit annotations to
> @system functions. Their code looks like this:
>
> --- clibrary.d
>
>     void monkey_around(...); // assumed @system-by-default
>
> ---
>
> Months or years later, I decide to write a D program that makes use of these
> bindings. By then, @safe-by-default has been fully implemented. I add
> `clibrary` as a dependency to my Dub project and write the following code:
>
> --- app.d
>
>     import clibrary;
>
>     void main() // @safe-by-default
>     {
>         /* ... code ... */
>
>         monkey_around(...);
>
>         /* ... more code ... */
>     }
>
> ---
>
> My program compiles with no errors...and then corrupts memory at run-time, even
> though every line of code I've written is @safe. Oops.
>
> This is the nightmare scenario that people are worried about: safety violations
> being introduced *silently* into existing, correct D code.

Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?
May 22, 2020
On Friday, 22 May 2020 at 05:37:55 UTC, Walter Bright wrote:
> On 5/21/2020 8:36 PM, Paul Backus wrote:
>> Something ought to be done to prevent this. It doesn't have to be the exact
>> proposal from the discussion thread, but doing nothing and allowing widespread
>> silent breakage cannot possibly be the best solution.
>
> I can see that happening. A simple example would be:
>
>     extern (C) void free(void* p);
>     ...
>     free(p);
>     free(p);
>
> The thing is, you are no worse off than now. If free() can be misused by calling it from system code, it can be misused by calling it from safe code.
>
> There's no way the compiler can detect this. If you annotate it, you'll just have to annotate it correctly. Forcing an annotation just means slapping @safe: at the beginning of the file and moving on - it's not going to help.

Currently, if I want to use @safe correctly, all I need to do is annotate my code with @safe and fix any compile errors that arise as a result.

With -preview=safedefault enabled, if I want to use @safe correctly, I am now required to *manually* review every extern function declaration in every module of every dependency of my program to make sure that they are explicitly annotated. If I do not do this, I risk introducing silent safety violations to my program.

You are correct that in both cases, I can run into trouble if @safe is misused. Nonetheless, I submit to you that I am worse off in the second case than in the first.

The compiler cannot be expected to guard against deliberate misuse, but it *can* be expected to give us the necessary tools to use @safe correctly. The current implementation of DIP 1028 does not do so.
May 22, 2020
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
> On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
>> This is the nightmare scenario that people are worried about: safety violations
>> being introduced *silently* into existing, correct D code.
>
> Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?

The problem isn't that safety is critical, it's that the D compiler is lying to me about the safety of my code.

If the compiler was honest and told me that my code was unsafe, I'd be able to make an informed decision to either (a) accept the lack of safety, or (b) do the additional work needed to make it safe. As-is, DIP 1028 takes that choice away from me, and I am forced to accept a lack of safety whether I want to or not. At that point, why not use C?