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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020