DIP 1028 is unsound.
DIP 1028 is deeply unpopular.
DIP 1028 is ridiculous.

How do we lessen the likelihood that DIPs like 1028 are accepted in the future?

DIP 1028 survived veto because the DIP author had a very low bar to jump over; he only had to convince one person that silently and globally calling extern(C) safe was sane.  Here are some ways to raise that bar:

1) Appoint an at-large language maintainer (LM) that steps in whenever either of the two LMs author a DIP.

2) Appoint an "emeritus" LM that can veto DIPs but is not required to actively approve them.  Andre?

3) Increase the number of LMs.

4) Some combination of the above.

If you have other, preferably simple, ideas on how to improve the DIP process, please chime in.  We may hit on something that could actually work.

If the LMs refuse amendment, and the governing docs provide no relief, DIP process dysfunction will remain a "vote with your feet" issue (the disaffected bleed away, growth stagnates, the community becomes ever more cynical and withdraws from DIP commentary, ...).

Finally, the elephant in the room: The DIP process would work much much better if Walter could somehow learn to communicate effectively in the forums.  Crucially, Walter often says that he believes he's answered a concern when the other, often highly respected, party most definitely believes he has not.  Evidently it requires the patience of Job and the clarity of Timon to get through to Walter.  Even that is not always enough.

On Thursday, 28 May 2020 at 00:05:19 UTC, Bruce Carneal wrote:
> DIP 1028 is unsound.
> DIP 1028 is deeply unpopular.
> DIP 1028 is ridiculous.
>
> How do we lessen the likelihood that DIPs like 1028 are accepted in the future?
>
> DIP 1028 survived veto because the DIP author had a very low bar to jump over; he only had to convince one person that silently and globally calling extern(C) safe was sane.  Here are some ways to raise that bar:
>
> 1) Appoint an at-large language maintainer (LM) that steps in whenever either of the two LMs author a DIP.
>
> 2) Appoint an "emeritus" LM that can veto DIPs but is not required to actively approve them.  Andre?
>
> 3) Increase the number of LMs.
>
> 4) Some combination of the above.
>
> If you have other, preferably simple, ideas on how to improve the DIP process, please chime in.  We may hit on something that could actually work.
>
> If the LMs refuse amendment, and the governing docs provide no relief, DIP process dysfunction will remain a "vote with your feet" issue (the disaffected bleed away, growth stagnates, the community becomes ever more cynical and withdraws from DIP commentary, ...).
>
> Finally, the elephant in the room: The DIP process would work much much better if Walter could somehow learn to communicate effectively in the forums.  Crucially, Walter often says that he believes he's answered a concern when the other, often highly respected, party most definitely believes he has not.  Evidently it requires the patience of Job and the clarity of Timon to get through to Walter.  Even that is not always enough.

As Mike Parker, the DIP manager, has just confirmed via email there are no governing documents regarding changing the DIP process, you just make suggestions to him directly.  That's refreshingly direct.  Here are the two that I've proposed:

1) Recruit an "at large" LM to stand in whenever a DIP authored by a regular LM is being considered.

2) Recruit Andre, or Timon or ... as a tie-breaker LM who can weigh in to break a tie between the two LMs (2 out of 3 wins).

It may be too much of an ask to get even these "part time" LMs but it's a start.  Whatever it takes to reduce cynicism and get things moving.

On Thursday, 28 May 2020 at 02:30:11 UTC, Bruce Carneal wrote:
> [...]
>
> 2) Recruit Andre, or Timon or ... as a tie-breaker LM who can

s/Andre/Andrei/?

On Thursday, 28 May 2020 at 02:33:35 UTC, Les De Ridder wrote:
> On Thursday, 28 May 2020 at 02:30:11 UTC, Bruce Carneal wrote:
>> [...]
>>
>> 2) Recruit Andre, or Timon or ... as a tie-breaker LM who can
>
> s/Andre/Andrei/?

Yep.

On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d <digitalmars-d@puremagic.com> wrote
>
> DIP 1028 is unsound.

No it is not

> DIP 1028 is deeply unpopular.

Show me the numbers. I do not see any proof

> DIP 1028 is ridiculous.

You have typo, you mean awesome?

On 28.05.20 09:52, Daniel Kozak wrote:
> On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote
>>
>> DIP 1028 is unsound.
> 
> No it is not
> ...

That's technically true. The issue is an existing hole in @safety, but one that gets exacerbated by a change in defaults.

https://dlang.org/spec/memory-safe-d.html

"Therefore, the safe subset of D consists only of programming language features that are guaranteed to never result in memory corruption."

`extern(C)` is not such a feature, so the existing behavior is in violation of the specification.

The hole can be plugged by changing a couple of lines of DMD's source code. Instead, Walter is now defending the @safety hole.

This is sending a weird message. Is this how we are going to deal with holes in `@safe` going forward? If so, what is the justification for the additional overhead necessary to make code `@safe` the proper way? At that point it seems like a reasonable solution to just opt out using `@system:` and/or use `@safe` merely as a linting mechanism and `@trusted` as a way to make the compiler shut up when it is convenient, which is exactly what Walter is worried about.

I think it is important that we can explain `@safe` with a straight face.

On Thursday, 28 May 2020 at 09:56:11 UTC, Timon Gehr wrote:
> On 28.05.20 09:52, Daniel Kozak wrote:
>> On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote
>>>
>>> DIP 1028 is unsound.
>> 
>> No it is not
>> ...
>
> That's technically true. The issue is an existing hole in @safety, but one that gets exacerbated by a change in defaults.
>
> https://dlang.org/spec/memory-safe-d.html
>
> "Therefore, the safe subset of D consists only of programming language features that are guaranteed to never result in memory corruption."
>
> `extern(C)` is not such a feature, so the existing behavior is in violation of the specification.
>
> The hole can be plugged by changing a couple of lines of DMD's source code. Instead, Walter is now defending the @safety hole.
>
> This is sending a weird message. Is this how we are going to deal with holes in `@safe` going forward? If so, what is the justification for the additional overhead necessary to make code `@safe` the proper way? At that point it seems like a reasonable solution to just opt out using `@system:` and/or use `@safe` merely as a linting mechanism and `@trusted` as a way to make the compiler shut up when it is convenient, which is exactly what Walter is worried about.
>
> I think it is important that we can explain `@safe` with a straight face.

Specially when all other modern system programming language do mark such external code as unsafe. Even Zig has a couple of open tickets regarding this.

D will need a very good marketing strategy to sell itself to security conscious crowd if this DIP is integrated this way.

Consider that D wasn't even mentioned on Chromium security post regarding what languages the team might consider to improve its security surface.

On Thursday, 28 May 2020 at 07:52:17 UTC, Daniel Kozak wrote:
> On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d <digitalmars-d@puremagic.com> wrote
>>
>> DIP 1028 is unsound.
>
> No it is not
>
>> DIP 1028 is deeply unpopular.
>
> Show me the numbers. I do not see any proof

Not exactly proof, but:
https://www.strawpoll.me/20184671/r

(The "@safe" option is what's proposed in DIP 1028.)

Am 28.05.20 um 12:49 schrieb Les De Ridder:
> On Thursday, 28 May 2020 at 07:52:17 UTC, Daniel Kozak wrote:
>> On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d <digitalmars-d@puremagic.com> wrote
>>>
>>> DIP 1028 is unsound.
>>
>> No it is not
>>
>>> DIP 1028 is deeply unpopular.
>>
>> Show me the numbers. I do not see any proof
> 
> Not exactly proof, but:
> https://www.strawpoll.me/20184671/r
> 
> (The "@safe" option is what's proposed in DIP 1028.)

I'm really missing a third option in that poll: The default for all declarations should be @safe, but extern(not-D) @safe declarations should be a compile error, regardless of if @safe is explicit or implicit. That forces an explicit decision between @system and @trusted for every extern(non-D) declaration.

On Thursday, 28 May 2020 at 11:13:07 UTC, Johannes Loher wrote:
...
>> 
>> Not exactly proof, but:
>> https://www.strawpoll.me/20184671/r
>> 
>> (The "@safe" option is what's proposed in DIP 1028.)
>
> I'm really missing a third option in that poll: The default for all declarations should be @safe, but extern(not-D) @safe declarations should be a compile error, regardless of if @safe is explicit or implicit. That forces an explicit decision between @system and @trusted for every extern(non-D) declaration.

The OP of the poll said: "People that think it should be @trusted, vote
@safe, it's pretty much the same thing." ...