DIP1000 observation

[Dennis]

On Monday, 26 August 2024 at 23:37:36 UTC, Jonathan M Davis wrote:
> Well, that does reduce the problem, but it still means that a 
> function which is perfectly @safe as long as you don't pass it 
> scoped types is either going to have to use scope for scoped 
> types to work, or the caller is going to have to cast away 
> scope.

As my example showed, there is no cast involved. The cast 
operator can't even be used for this purpose. All you need is the 
caller to be `@system` or `@trusted`, which without dip1000 must 
be the case anyway since you're taking the address of a local.

> And honestly, if @system and @trusted functions can accept 
> scope data without having to cast away scope

It's about whether the call site is `@system` or `@trusted`, not 
the called function.

> Attribute inferrence will both reduce the problem by making 
> some stuff just work and increase the problem by introducing 
> scope in places that wouldn't otherwise have it.

(...)

> that will probably just increase how much I use @system instead 
> of @safe and overall result in more memory safety issues in my 
> code,

Are you aware that DIP1000 strictly reduces the amount of 
`@system` / `@trusted` code you need?

And also that adding / inferring `scope` to a parameter is always 
a strict improvement for the caller of the function with that 
parameter?

If you can find a counterexample, where enabling dip1000 would 
require more `@system` code without relying on the current bug 
that slicing locals is allowed in `@safe` functions, or an 
example where inferring / adding `scope` to a parameter adds 
restrictions to the call site, please post it here or on a 
bugzilla.