On Friday, 29 May 2020 at 20:36:12 UTC, Walter Bright wrote:
> Kenny G (famous clarinet player)

Soprano saxophone, not clarinet. They look similar, and are both Bb instruments (I know there are non Bb clarinets), but they don't sound that similar to me. Kenny G is also sometimes heard on other saxes, but  I've never heard him on clarinet.

On 5/29/2020 3:36 AM, Ali Çehreli wrote:
> Thank you! Which meme did it? :o)

My secret!

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

I wouldn't disagree with being made inclusive on the final decision making (though in this case I don't think it would have changed the outcome).

However, I would regard myself as a language implementer, not a language designer (nor library maintainer).

On 5/29/2020 2:53 AM, solidstate1991 wrote:
> Can we get a compiler flag that will enable safe by default for people who might want it?

It would balkanize the language.

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

I don't think this is the best way forward.

Though I've only skim read the discussion thread (mostly only reading posts by those I know in person), I am inferring that both extremes - extern @safe and extern @system - both suffer from the same defect in DIP 1018 with regards to the greenwashing problem.  It also looks like all current suggestions for a compromise on the matter are pretty woeful as well (though I don't pretend to have read them all).

It seems that there will have to be some restrictions in place that prevent inappropriate annotations, at the cost of long deprecations and breaking existing code.

I don't see any point in listing any such rules though unless the dip process is restarted.

On 5/29/2020 2:38 PM, Adam D. Ruppe wrote:
> On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
>> The idea is the simple, general rule that:
> 
> There's already exceptions to that.
> 
> public public void foo() {}
> 
> is an error, whereas
> 
> public:
>    public void foo() {}
> 
> is not.

Is it really an exception?

public public:  // error
public public { } // error


> Let's say "attribute: changes the default attribute set of non-inferred subsequent declarations. attribute{} changes the default attribute set of non-inferred child declarations."

The inferred set changes over time, this would become problematic.

On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
> On 5/29/2020 2:07 AM, Timon Gehr wrote:
>> It would be great if `@safe:` did not affect declarations that would otherwise infer annotations.
>
> The idea is the simple, general rule that:
>
>   attribute declaration;
>   attribute { declaration; }
>   attribute: declaration;
>
> behave the same way.

To preserve this, then please can we have `@safe module foo;`. This would change the default on a module basis to @safe, but still infer e.g. function template bodies as @system where necessary. This feature would allow modules from different projects, including ones written before this feature would be added can coexist happily. There would be no breakage, unlike DIP 1028 (which I BTW would support at a lower preference than the above feature, apart from unmarked extern(C) declarations being @safe).

On Friday, 29 May 2020 at 21:38:40 UTC, Adam D. Ruppe wrote:
> On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
>> The idea is the simple, general rule that:
>
> There's already exceptions to that.
>
> public public void foo() {}
>
> is an error, whereas
>
> public:
>   public void foo() {}
>
> is not.
>
>> Having a simple, general rule with maybe a less favorable effect here and there is preferable to a complex set of special cases that try to do the optimal thing in each case.
>
> Often many things can be a simple, general rule based on how you word it.
>
> Let's say "attribute: changes the default attribute set of non-inferred subsequent declarations. attribute{} changes the default attribute set of non-inferred child declarations."
>
> That is simple and covers the cases sensibly. Big step up from where we are today.

This seems like a good idea. Simple and enabling.

On 5/30/20 7:39 AM, Nick Treleaven wrote:
> On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
>> On 5/29/2020 2:07 AM, Timon Gehr wrote:
>>> It would be great if `@safe:` did not affect declarations that would otherwise infer annotations.
>>
>> The idea is the simple, general rule that:
>>
>>   attribute declaration;
>>   attribute { declaration; }
>>   attribute: declaration;
>>
>> behave the same way.
> 
> To preserve this, then please can we have `@safe module foo;`. This would change the default on a module basis to @safe, but still infer e.g. function template bodies as @system where necessary. This feature would allow modules from different projects, including ones written before this feature would be added can coexist happily. There would be no breakage, unlike DIP 1028 (which I BTW would support at a lower preference than the above feature, apart from unmarked extern(C) declarations being @safe).

+1 this would be perfect.

Not sure if this would work either, but both of these are already reserved words:

default @safe:

-Steve

On Saturday, 30 May 2020 at 16:17:49 UTC, Steven Schveighoffer wrote:
>
> +1 this would be perfect.
>
> Not sure if this would work either, but both of these are already reserved words:
>
> default @safe:
>
> -Steve

It would probably have to be something more like `default(@safe)`, since `default @safe:` ought to mean the same thing (in principle) as `default: @safe:`.