On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
> The subject says it all.
>
> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
>
> For everyone else, carry on as before.

Thank you Walter. I am sure this was not an easy decision, and I respect how you have handled the response.

I think one important takeaway from this should be that people were not opposed to "memory safety by default." Instead, they were opposed to "@safe in its current implementation by default."

In terms of changing the behavior of @safe, I think it would be useful to review comments on this old bug report [1] about changing @safe to a whitelist instead of blacklist. I think if @safe was a whitelist instead of a blacklist, the concerns about @safe's current implementation would be diminished.

I also think some of the comments on the thread discussing the DIP procedure are also relevant for improving the DIP process going forward. In particular, creating a small DIP committee, perhaps consisting of the Language Maintainers, the principal maintainers of LDC and GDC, and maybe one person elected by the community (hopefully Andrei if he has time to volunteer), that would discuss each DIP before voting might help make a more robust decision. If the current process is continued, then we could add a rule that the DIP author may not participate in final DIP votes and he should be replaced by an alternate. I'm not sure how important that would be with a committee-based approach, but worth considering.


[1] https://issues.dlang.org/show_bug.cgi?id=12941

On Friday, 29 May 2020 at 11:04:00 UTC, jmh530 wrote:
> On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
>> [...]
>
> Thank you Walter. I am sure this was not an easy decision, and I respect how you have handled the response.
>
> [...]

I would think that Phobis maintainers would make good candidates here.

On 5/29/20 12:53 AM, Walter Bright wrote:
> The subject says it all.
> 
> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
> 
> For everyone else, carry on as before.

Thank you Walter.

I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece.

It would be nice to be able to put @safe: at the top of all modules. This was in fact the first thing I tried when migrating the mysql-native package to be @safe compliant [1]. And it did work for a few modules quite well. There are a few snags though:

1. Templates should be inferred rather than stamped @safe
2. Class methods do not inherit this attribute

So I think @safe by default (for D-compiled code) would be ideal and provide the most utility.

-Steve

[1] https://github.com/mysql-d/mysql-native/pull/214

On Friday, 29 May 2020 at 12:22:07 UTC, Steven Schveighoffer wrote:
> On 5/29/20 12:53 AM, Walter Bright wrote:
>> The subject says it all.
>> 
>> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
>> 
>> For everyone else, carry on as before.
>
> Thank you Walter.
>
> I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece.

It's not unfortunate - it's unnecessary. @safe by default is still a laudable and (seemingly) attainable goal. Why throw out the entire DIP instead of removing or altering the controversial aspect?

On 5/29/20 12:53 AM, Walter Bright wrote:
> The subject says it all.
> 
> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
> 
> For everyone else, carry on as before.

Thank you.

Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.

On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
> ...
> Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.

I think you should. To be honest first I thought it was a fake account, because your behavior wasn't great (Technically speaking).

SG.

On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
> The subject says it all.
>
> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
>
> For everyone else, carry on as before.

This is sad news. I was excited for @safe-by-default, and had hoped that the issue with extern(C) could be solved without throwing DIP 1028 away entirely.

I hope that you and Atila do not take the reception of DIP 1028 as a blow against @safe in general, and that you will continue to look for ways to improve the safety of the D language.

On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
> On 5/29/20 12:53 AM, Walter Bright wrote:
>> The subject says it all.
>> 
>> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
>> 
>> For everyone else, carry on as before.
>
> Thank you.
>
> Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.

By my lights you've already set a high standard.  Certainly I have further to go in that regard than you do.  Timon and others also continue to impress.

Thanks again to Walter for crossing any divide which the loyal opposition may have thrown up.

On 2020-05-29 16:13, SashaGreat wrote:
> On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
>> ...
>> Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.
> 
> I think you should. To be honest first I thought it was a fake account, because your behavior wasn't great (Technically speaking).
> 
> SG.

Same here

On 2020-05-29 16:22, Paul Backus wrote:
> On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
>> The subject says it all.
>>
>> If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best.
>>
>> For everyone else, carry on as before.
> 
> This is sad news. I was excited for @safe-by-default, and had hoped that the issue with extern(C) could be solved without throwing DIP 1028 away entirely.
> 
> I hope that you and Atila do not take the reception of DIP 1028 as a blow against @safe in general, and that you will continue to look for ways to improve the safety of the D language.

Agreed, from a novice perspective @safe by default looks like the way to go.