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.

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.

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

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.

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.

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.

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.