On Friday, 31 May 2024 at 11:42:13 UTC, Dukc wrote:
> Nick Treleaven kirjoitti 31.5.2024 klo 12.18:
>> @safe should mean mechanically checked for accidental memory-safety violations - that is a more useful definition. Allowing non-extern(D) linkage prototypes to be @safe breaks that principle and makes @safe prototypes a minefield.
>
> I agree in principle, but note this is orthogonal to the DIP. D allows declaring external C functions as `@safe` right now. The DIP should not make it any worse, and it also doesn't prevent a separate proposal that would say that external non-D linked functions must be either `@trusted` or `@system`.

This. I don't think we can stop programmers intent on lying to the compiler. As mentioned there's already `pragma(mangle)`, they can write assembly, ...

I think that if there's a body written in D somewhere, it's unlikely someone will manually write a declaration and use the wrong attribute by mistake. And if there isn't, then they will have had to deliberately have picked an attribute.

On Friday, May 31, 2024 7:06:16 AM MDT Paul Backus via dip.ideas wrote:
> Inference also solves the wrong-default problem for @nogc, nothrow, and pure, in addition to @safe, without the need for any additional -preview switches or migrations. Asking users to migrate from @system-by-default to @safe-by-default may be doable, but can we really ask them to do the same thing *three more times* for the other attributes?

I think that you will have a hard time finding a consensus on the idea that any of those should be the default. It may be that most folks would agree that @safe should be the default, but I'd be _very_ surprised to see a consensus on the others (especially @nogc).

Personally, I'm increasingly of the opinion that most attributes are actively detrimental rather than beneficial, and I don't want to see them be forced or for them become the default. I think that there's a good argument for making @safe the default given that you usually do want most code to be @safe, and @trusted makes it fairly easy to have @system code be used by @safe code, but the others often simply do not work with code and get in the way of making changes - especially with larger code bases. So, I very much hope that we don't change the default attributes beyond possibly @safe.

And considering that DIP 1000 is a thing, I'm definitely concerned about what the repercussions of making @safe the default are, since DIP 1000 makes life _way_ too complicated IMHO, and inference will trigger it in a number of cases (to the point that I would be tempted to slap @system on everything and give up on any benefits from @safe just to escape having to deal with DIP 1000). If DIP 1000 weren't a thing, then I'd probably be okay with @safe being the default, but I think that all of these attempts to make malloc @safe instead of just saying that if you want @safe without @trusted, you use the GC, are adding way too much complexity to the language, and making @safe the default potentially forces you into that mess - either that or forces you to slap @system all over the place.

Having more attribute inference may help with some of these issues, but personally, I just want to avoid most attributes in general and not have to deal with stuff like pure, because inevitably, at some point, you have to figure out how to strip it from your code to get something to work.

- Jonathan M Davis

On 5/30/24 20:35, Atila Neves wrote:
> https://github.com/atilaneves/DIPs/blob/safe-by-default/safe-by-default.md
> 
> Destroy!

- I think even more important than the default is the ability to change the default (e.g. `default(@safe):`). This does not exist currently, but it would be required for easy migration.

- There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.

- The DIP should clarify whether annotations like `@safe:` apply to prototypes or whether prototypes always need an individual annotation.

- N.B.: OpenD has been experimenting with changing the default safety level behavior to be a distinct category from the other three. (It enables checks on pointer arithmetic, but is not transitive and does not include DIP1000 checks.) It does not guarantee memory safety but can catch bugs.