https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md

Thanks for the reminder, ``a.ptr`` is a perfectly safe operation, it exists solely because we do not have type state analysis to prevent dereferencing null. It can be a valid argument to non-D code both as null and non-null. That check should be removed.

I see there is one other example given, for escape analysis. This is where I actually see the value in such a proposal and have thought about as part of my own proposals.

Specifically for type state analysis, it is never correct to dereference null, therefore it should never be allowed in ``@system` code.

I should mention, I did not consider the escape analysis in the form proposed as being turned on. Depending on how the analysis works, this could throw up a lot of false positives, where you want it to be highly liberal in what is allowed.

Each error will need confirmation that it is liberal in what it allows, and is highly cherry picked on what it disallows. But we can do this on a case by case basis, not here.

On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md

The DIP says

> Most code is likely written as the default, and the idea is to move such code to @safe.

Does that mean this is intended to be a transitional feature to help users migrate their code to a future @safe-by-default edition of D? Or are we giving up on @safe-by-default, and replacing it with this proposal?

On 9/23/2024 5:24 AM, Paul Backus wrote:
> Does that mean this is intended to be a transitional feature to help users migrate their code to a future @safe-by-default edition of D? Or are we giving up on @safe-by-default, and replacing it with this proposal?

It means our current method of all-or-nothing with @safe is a bridge too far for a lot of code.

Whether it is transitional or not, the more errors detected at compile time, the better.

`a.ptr` is an array overflow issue, not a pointer validation issue, as one can have an array of 0 length.

On 24/09/2024 1:13 AM, Walter Bright wrote:
> `a.ptr` is an array overflow issue, not a pointer validation issue, as one can have an array of 0 length.

That is a good point, the pointer can be non-null, but length is zero.

At which point yes, can overflow.

Ok, do a length check first and the safety check can be disabled. I'm ok with that!

On Monday, 23 September 2024 at 12:43:03 UTC, Walter Bright wrote:
> On 9/23/2024 5:24 AM, Paul Backus wrote:
>> Does that mean this is intended to be a transitional feature to help users migrate their code to a future @safe-by-default edition of D? Or are we giving up on @safe-by-default, and replacing it with this proposal?
>
> It means our current method of all-or-nothing with @safe is a bridge too far for a lot of code.
>
> Whether it is transitional or not, the more errors detected at compile time, the better.

In that case, I'm strongly opposed to this.

Fundamentally, this proposal does nothing to make writing @safe code easier; it just makes writing non-@safe code more annoying. It's the bad part of @safe-by-default without the good part.

If you're looking for a less all-or-nothing approach to increasing the adoption of @safe, allow me to once again recommend universal attribute inference:

https://forum.dlang.org/thread/pfawiqhppkearetcrkno@forum.dlang.org

On 9/23/2024 6:17 AM, Paul Backus wrote:
> If you're looking for a less all-or-nothing approach to increasing the adoption of @safe, allow me to once again recommend universal attribute inference:

I'm well aware of universal attribute inference. There are also a number of technical problems with it. Meanwhile, we have a lot of legitimate and easy checks that are already implemented, we just have to enable them.