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.

On 1/2/20 6:19 AM, jmh530 wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
> 
> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).
> 

So I spent about 3 days to try and bring a large project into the realm of `@safe` [1]. I'm still not done there, but it's both eminently possible, and satisfying to have something to show for "you can just mark all your stuff @safe". However, one of the biggest costs we are going to have for this DIP (and I 100% support this DIP), is that deprecations are not going to be easy. It's not always easy to take your well-crafted API, and make it usable in both `@safe` and `@system` code.

The two large issues I ran into (and these I think we need to have fixed in concurrence with this release):

1. std.variant.Variant cannot be @safe. We need a SafeVariant. I went with TaggedAlgebraic due to the nice generative features there.

2. Object.opXXX is NOT marked @safe. This means doing operators with objects (especially opEquals). In my PR, because I no longer needed to compare objects since I was moving away from Variant (which uses TypeInfo for checking runtime type), this problem kind of went away. But it's definitely something that is concerning.

These are likely not the only problems that will happen. And most likely we will see a lot of these little things crop up. The DIP should address not just schedules, but prerequisites for moving to the next stage of the process (e.g. Object must be usable with @safe before an official deprecation is added to the compiler).

If you read through the discussions on making MySQL safe (see the referenced issue report [2]), the biggest difficulty for me is if you need to change return types (as I did from Variant to TaggedAlgebraic). Now, your API needs to necessarily adjust because you can't overload based on return type in D. If that were possible, then the API updates and deprecations would be easy.

Is it even feasible to overload something like return type based on the context called from? i.e. if you call from a @system function, you get type A, if you call from a @safe function, you get type B.

-Steve

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

On 1/2/20 4:47 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
> 
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md 
> 
> 
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
> 
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
> 
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
> 
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> 
> *Please stay on topic!*
> 
> Thanks in advance to all who participate.

Some sticky points:

1. Currenty the compiler can "give up" on attribute inference, and therefore leaves functions as @system. What happens when @safe is the default? I would recommend that they should be inferred @safe, but this might be a code-breaking in some cases.

2. I'll echo here what other have said, because it's REALLY important: do NOT recommend slapping @trusted on anything. It's a very very bad idea, and destroys the whole concept of @safe. Rather, put @system on functions that have to be @system.

-Steve

On 1/3/20 6:06 AM, Walter Bright wrote:
> On 1/2/2020 10:31 PM, Mathias Lang wrote:
>> On paper, this sounds like a great idea. Make '@safe' the default so people have to opt out of memory safety rather than opt-in. However, we have extensive experience with those changes (and how they are handled), and I am not, as it stands, in favor of it.
> 
> Modules can be labeled as @system by beginning them with:
> 
>     @system:

This does not work for member functions (also a valid criticism of the suggestion to mark a module @safe)

It also is almost always not what you want, as this then forces templates to be @system.

In other words, marking @safe: at the top makes sense, you can fix all the compiler errors that result.

Putting @system: at the top is not going to have the same effect, things that really are @safe will work when marked as @system. You want as LITTLE as possible to be marked @system, not a blanket marking.

This should not be a suggestion. Take the time to assess why a function is not working, and mark it @system only if it needs to be.

-Steve

On 1/2/20 12:38 PM, H. S. Teoh wrote:
> On Thu, Jan 02, 2020 at 05:27:22PM +0000, Arine via Digitalmars-d wrote:
>>>   Fortunately, the solution is easy, although tedious: annotate
>>>   functions that aren't safe with @trusted or @system.
>>
>> If you could annotate the module with @system to use the old behavior,
>> this will ease the transition period. This is better than simply
>> having a compiler flag that changes behavior, as you can see in the
>> code that is using the old behavior. You can also disable it per
>> module, not either on or off for everything.
>>
>>
>>      @system module std.stdio; // or similar
> 
> You can already do this today:
> 
> 	module blah;
> 	@system:
> 	... // everything here defaults to @system
> 
> Of course, today this does nothing because @system is the default, but
> you can already mark an entire module as @safe the same way, for
> example.

This is erroneous. It marks all templates @system, which would otherwise be inferred @safe.

And it does not mark member functions.

I think the idea of marking a module @system is good, but the usage is confusing. What you want to affect is the *default* assumption.

You need a pragma.

-Steve

On Friday, 3 January 2020 at 15:38:02 UTC, Steven Schveighoffer wrote:
> This is erroneous. It marks all templates @system, which would otherwise be inferred @safe.
>
> And it does not mark member functions.


I think it applies only to other attributes.

import std.traits;

@system:

struct S {
  void func()()
  {
  }
}

static assert(!isSafe!(S.func!()));

On 1/3/20 10:48 AM, Eugene Wissner wrote:
> On Friday, 3 January 2020 at 15:38:02 UTC, Steven Schveighoffer wrote:
>> This is erroneous. It marks all templates @system, which would otherwise be inferred @safe.
>>
>> And it does not mark member functions.
> 
> 
> I think it applies only to other attributes.
> 
> import std.traits;
> 
> @system:
> 
> struct S {
>    void func()()
>    {
>    }
> }
> 
> static assert(!isSafe!(S.func!()));


It seems you are right! But I could have sworn I had to mark member functions as @safe when modifying projects to be @safe. I'll have to re-check and see if there are cases where it doesn't work.

-Steve

I'm glad we're finally opening this can of worms. IMO, it's worth whatever breakage it causes, or to turn that around, no price is too high to have @safe be the default. It's also a great PR point for D to be memory safe by default.

On Friday, 3 January 2020 at 05:57:09 UTC, Jesse Phillips wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
>> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>>
>
> I think the DIP should specify the depreciation plan. Currently it only mentions it would be available through --preview (is it not expect to go further?

I think this could even be as simple as, "a new DIP will be created defining a plan for timing and requirements to make this default"

I think many are hung up on the fact that this DIP is only specifying a preview switch and not the actual change to the language.

Rightly so, DIPs are about the end game. We don't have a good plan for making these larger breaking changes. I did try to start such a discussion because I saw these coming.

https://forum.dlang.org/post/bfgpindcvbjmxscsgudh@forum.dlang.org

Other replies please us a separate thread to discuss release planning. Let's help to define the DIP improvement so Walter can move forward.

On Friday, 3 January 2020 at 14:36:26 UTC, Adam D. Ruppe wrote:

> Good: I suspect a majority of D code already qualifies for @safe.

Correct.

> The pain impact is likely to be small,

This is also my prediction.

> and with the default set correctly, more libraries will work and those benefits can bubble up to user code.

Correct.

> Bad: It is a bit of a hassle to deal with breakage when it comes up and the benefit is likely to be small, since most code is already free of the trouble it aims to solve.

This can be gauged easily. Walter already has a PR, all we (me in all likelihood) have to do is try it on Phobos then packages from code.dlang.org.

> I fall a bit on the "yes" side since I do think the good slightly outweighs the bad.

@safe by default is strategically important for the language.

> But let's not unfairly trash D as it stands to make this case stronger. We're already streets ahead of C++ even without this dip so talking about bad experiences and overall statistics from C and C++ don't necessarily apply to D.

One never knows how code in the wild is written, but with DIP1000 turned on and using only the GC, it's extremely rare for me to write code that doesn't qualify as @safe even if not explicitly marked that way (but I always do).