On 1/2/2020 9:27 AM, Arine wrote:
> 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

We already have that in starting a module with:

    @system:


> C# and Rust both are first class citizens for safety, they don't require hacks like using a lambda to declare a section of code as unsafe as you have to do in D.
> 
> 
> @safe void foo() {
> 
>      // ...
> 
>      () @trusted {
>          // ...
>      } ();
> 
>      // ...
> }
> 
> Since this DIP is so bare bones anyways, I'd be inclined to include these changes as part of this DIP.

This DIP is not about changing how trusted code is inserted. If you'd like to discuss that, please start a separate thread. Please keep this thread on-topic about the DIP.

On Thursday, 2 January 2020 at 21:29:48 UTC, JN wrote:
> encounter a crash, usually all you have to do is just go over the unsafe sections (which should be rare and limited in size) to find the culprit.

or just open the debugger and it tells you exactly where it happened.

I'm slightly in favor of this dip, I've said before that as it is, the annotations are more hassle than they are worth, but think the swapped defaults would push it slightly over the edge. (I kinda feel the same about pure, nothrow, etc but it does get murkier there, especially since there's no equivalent to @system and @trusted there!)

But the aid in debugging I don't think would help that much, it would be more about just making it lower cost for small library functions to adopt them, which would hopefully fan up to to other levels too.

On Friday, 3 January 2020 at 01:23:01 UTC, Walter Bright wrote:
> On 1/2/2020 6:39 AM, 12345swordy wrote:
>> This issue is major blocking point
> 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

Done,
https://issues.dlang.org/show_bug.cgi?id=15246

On 03.01.20 02:31, Walter Bright wrote:
> On 1/2/2020 9:27 AM, Arine wrote:
>> 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
> 
> We already have that in starting a module with:
> 
>      @system:
> 

This will not result in the old behavior. It will disable inference of @safe in that module.

On Friday, 3 January 2020 at 01:24:17 UTC, Walter Bright wrote:
> On 1/2/2020 6:39 AM, 12345swordy wrote:
>> This dip, doesn't describe how to make the destroy function for classes safe, as the class deconstructors don't inherent the attributes from the parent class.
>
> 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.

What about bugs for @safe that require an DIP to fix then? Your dip doesn't address this at all. Your strategy seems to make it safe by default and not worry about any code that may be broken from using unsafe language features that can not be simply fix with a pull request. I don't see how this is in any way off-topic here. Is your current workaround for this is to abused the @trusted feature?

On Friday, 3 January 2020 at 01:31:26 UTC, Walter Bright wrote:
> This DIP is not about changing how trusted code is inserted. If you'd like to discuss that, please start a separate thread. Please keep this thread on-topic about the DIP.

If issues with @safe aren't going to be considered with this DIP, then I'd say this DIP should be delayed until issues with @safe are resolved before forcing it as the default. Don't think I can think of a language that is safe by default that needs to use a hack with a separate language feature to get desired behavior.

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?

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 would part of the rational would be: A large portion of functions should find themselves performing safe operations. Leaving off prevents the use of safe functions which were not evaluated for safety (safe functions remain usable in system functions).

This would be the same rational to apply nothrow by default. Though it may not have the same qualities of benefits.

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":
>

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.

First, because '@safe', and attributes by extension, is currently not a practical tool, and even not usable in some cases. It is currently painful to mix differently-attributed code if you are not going full template (e.g. classes, delegates). I've worked for two companies using D, and none of them used @safe, and were more on the low-level side of things.
In fact, @safe wouldn't even have prevented most of the bug we had, as they were fibers stack overflow (I'm sure any fiber user know what I'm talking about).

Second because those kind of changes have historically been badly handled, as the impact is not fully assessed. For such a large and impactful change, I would expect the proposer of the DIP to assess the impact of this change on a few projects, in order to provide a data point. Either go with major D projects, and/or pull a sample for the dub registry, to gauge the hassle, performance and readability degradation it can bring.
Yet DMD is not @safe. Neither is druntime. DUB, Vibe.d ? Neither. And I've seen countless places where '@safe' is either forced on the user (by forcing the user to provide '@safe' routines), or just bypassed by means of '@trusted'. Just take a look at Vibe.d.
Side note, using this flag to compile Phobos would most likely result in link failures, like it did with DIP1000.

Third, we start to have a few DIPs piling up in the -preview section. DIP25, DIP1000, DIP1008. Some libraries use it, some don't, and adding more features there will only balkanize the language more. Let's not repeat the `std.experimental` experience with the compiler, and actually finish what we started.

TL;DR: Disruptive change that requires every D user to put some work to support it (possibly many months worth of work), yet no evidence that a single large-scale project have been experimented with while writing this DIP.

On Fri, Jan 03, 2020 at 01:46:20AM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]
> I'm slightly in favor of this dip, I've said before that as it is, the annotations are more hassle than they are worth, but think the swapped defaults would push it slightly over the edge. (I kinda feel the same about pure, nothrow, etc but it does get murkier there, especially since there's no equivalent to @system and @trusted there!)
[...]

I'm for this DIP, but have reservations about the extent of code breakage it's going to cause and how to mitigate that.

Just out of curiosity, I took one of my current projects this morning and started putting @safe: on top of every file, just to see how far I got.

I quickly ran into the issue that delegates are @system by default, so I have to manually stick @safe onto every one of them, which is a hassle, but I suppose wouldn't be a problem once @safe becomes default. But it also leads to another issue: generic code can't reasonably just throw @safe onto every delegate type, because sometimes you *want* to support @system delegates.  There are various ways of mitigating this, of course, but it involves a lot more code rewriting than I'd like to have when this DIP takes effect.

Another issue is that taking the address of locals is verboten in @safe code. It's generally found in self-contained code, but becomes a problem across 3rd party library API boundaries: if an API requires a pointer there's not much you can do about it without waiting for an upstream fix (which will break API with older code). I suppose @trusted lambdas would be a workaround, but it does greatly uglify otherwise already-working code and again requires effort to rewrite/work around.

So we better have a good, practical implementation schedule before merging this DIP.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel