www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Preventing another 1028

reply Bruce Carneal <bcarneal gmail.com> writes:
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.
May 27
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
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.
May 27
parent reply Les De Ridder <les lesderid.net> writes:
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/?
May 27
parent Bruce Carneal <bcarneal gmail.com> writes:
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.
May 27
prev sibling next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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?
May 28
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
May 28
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
May 28
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2020 2:56 AM, Timon Gehr wrote:
 [...]
There's a lot of imprecise language in the D spec, as I'm not very good at language lawyering, and much of it was written hastily. A couple years ago I started doing this section by section, but ran out of steam as my PRs were met with indifference and languished. There's also the factor of experience showing weaknesses in the spec. Subsequent language changes often do not show up in the spec. The safe stuff was written a seeming lifetime ago. The precise language for safe can certainly be improved, as has been done already for what a " safe interface" is.
May 28
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Thursday, 28 May 2020 at 21:35:38 UTC, Walter Bright wrote:
 On 5/28/2020 2:56 AM, Timon Gehr wrote:
 [...]
There's a lot of imprecise language in the D spec, as I'm not very good at language lawyering, and much of it was written hastily. A couple years ago I started doing this section by section, but ran out of steam as my PRs were met with indifference and languished.
I offered last year to work on the spec. But even a simple PR got stuck because the only person who can apparently say anything about the language is yourself and despite repeated requests there was no response. I eventually gave up. I am again willing to try but it is not possible to make progress without your prompt input as no one else really understands why things are as they are.
May 28
prev sibling parent reply Les De Ridder <les lesderid.net> writes:
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.)
May 28
parent reply Johannes Loher <johannes.loher fg4f.de> writes:
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.
May 28
parent reply Les De Ridder <les lesderid.net> writes:
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." ...
May 28
parent Johannes Loher <johannes.loher fg4f.de> writes:
On Thursday, 28 May 2020 at 11:31:35 UTC, Les De Ridder wrote:
 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." ...
It is absolutely not. It is a completely different thing. I'm saying that if you don't annotate extern(non-D) explicitly with system or trusted, it should be a compile error. That means, there is no „default“ at all.
May 28
prev sibling parent reply IGotD- <nise nise.com> writes:
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.
I think one of the biggest problems is the expectations of the management model. DIP 1028 has issues where a lot of people disagreed and valid criticism, yet it was accepted on the first round. Is this a community development model? Perhaps D should go towards a committee model instead. This might be a better model for Walter and those who has a clear vision of how D should evolve, despite unpopular changes.
May 28
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 28 May 2020 at 13:01:43 UTC, IGotD- wrote:

 I think one of the biggest problems is the expectations of the 
 management model. DIP 1028 has issues where a lot of people 
 disagreed and valid criticism, yet it was accepted on the first 
 round. Is this a community development model? Perhaps D should 
 go towards a committee model instead. This might be a better 
 model for Walter and those who has a clear vision of how D 
 should evolve, despite unpopular changes.
The DIP went through one round of community review and one round of final review just like every other DIP does. Some go through multiple rounds of community review when the DIP author significantly modifies the DIP after the first round in response to feedback. It is *always* up to the DIP auhtor to accept that feedback or to reject it. Please read the DIP process documentation: https://github.com/dlang/DIPs
May 28
prev sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Thursday, 28 May 2020 at 13:01:43 UTC, IGotD- wrote:
 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.
I think one of the biggest problems is the expectations of the management model. DIP 1028 has issues where a lot of people disagreed and valid criticism, yet it was accepted on the first round. Is this a community development model? Perhaps D should go towards a committee model instead. This might be a better model for Walter and those who has a clear vision of how D should evolve, despite unpopular changes.
The duopoly model has strengths and weaknesses as do others. In the case of 1028 the duopoly model was abused. We no longer had 2 experts looking out for the community, we only had one, Atila. We can fix that in the future by altering the DIP process. I have proposed such a modification to Mike. Per email with Mike other modification proposals are welcome and can be submitted in this thread. Side note: I think Mike has done a very good job. It's the DIP process itself that could use some help.
May 28
parent Bruce Carneal <bcarneal gmail.com> writes:
On Thursday, 28 May 2020 at 14:16:00 UTC, Bruce Carneal wrote:
 On Thursday, 28 May 2020 at 13:01:43 UTC, IGotD- wrote:
 On Thursday, 28 May 2020 at 00:05:19 UTC, Bruce Carneal wrote:
 [snip]
I think one of the biggest problems is the expectations of the management model. DIP 1028 has issues where a lot of people disagreed and valid criticism, yet it was accepted on the first round. Is this a community development model? Perhaps D should go towards a committee model instead. This might be a better model for Walter and those who has a clear vision of how D should evolve, despite unpopular changes.
The duopoly model has strengths and weaknesses as do others. In the case of 1028 the duopoly model was abused. We no longer had 2 experts looking out for the community, we only had one, Atila. We can fix that in the future by altering the DIP process. I have proposed such a modification to Mike. Per email with Mike other modification proposals are welcome and can be submitted in this thread. Side note: I think Mike has done a very good job. It's the DIP process itself that could use some help.
For ease of reference, I repeat here the two proposals I've made to Mike: 1) Recruit an "at large" LM to stand in whenever a DIP authored by a regular LM is being considered. 2) Recruit Andrei, 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). As noted in the email to Mike, even asking someone to be one of these "part time" LMs is a big ask but we've got to start somewhere. The first proposal addresses the duopoly weakness exposed by 1028. The second proposal is a much bigger deal and is intended to get us past single person veto mistakes. It should also reduce cynicism and promote engagement. If you've got other ideas on how the DIP process could be improved, please submit them here.
May 28