DIP 1028---Make @safe the Default---Community Review Round 1

[jmh530]

On Friday, 3 January 2020 at 01:27:11 UTC, Walter Bright wrote:
> [snip]
>
> Issues that don't get put in bugzilla don't get fixed. Please 
> tag all issues about @safe with the `safe` keyword. Here is the 
> current list:
>
> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=229570&query_format=advanced
>
> Issues with @safe that are not about making @safe the default 
> (i.e. not about the DIP) are off-topic. Please start a new 
> thread with them.

You made the argument further down that we shouldn't need to act 
serially, but I don't think I'm the only one who disagrees with 
that stance. It is a question of strategy. I strongly believe 
that questions of strategy are on-topic for discussing this DIP, 
particularly when the strategy is not laid out in the DIP itself.

Going back several years, there are have been Vision documents 
that highlight a goal of moving away from the GC and instead 
using Reference Counted types. However, it has been found to be 
difficult to do this @safe-ly. This is not something I am pulling 
out of thin air. This is something you, Andrei, and others have 
talked about extensively and certainly know a lot more about than 
I do. As a result, there have been a series of language 
enhancements aimed at strengthening @safe. More recently, there 
was a blog post where Atila laid out his Vision for making @safe 
by default.

 From a strategic perspective, I wonder, has the language been 
enhanced to the point that it makes sense for @safe to be the 
default. This is not addressed in the DIP. It seems to me that we 
are not to the point where it is possible to do @safe RC, which I 
assumed was a major long-term goal for the language. So I wonder 
if it is appropriate to make the change, given the breakage and 
the fact that @safe is still on track to be strengthened further.

Others have argued for making it opt-in until these other 
language improvements are ready. I consider that an on-topic 
valid point as well.