DIP1000 observation

[Dennis]

On Tuesday, 27 August 2024 at 12:16:23 UTC, Jonathan M Davis 
wrote:
> It only reduces the amount of @system or @trusted code you need 
> if you're willing to mark up code with scope, which I am not.

No it doesn't. Look at my code example again, there's no `scope` 
anywhere in there!

Consider taking the address of a local in all 3 safety scenarios, 
both before and after enabling dip1000:

|          | No dip1000  | dip1000      |
| -------- | ----------- | ------------ |
| @system  | No checks   | No checks    |
| @trusted | No checks   | No checks    |
| @safe    | Not allowed | Scope checks |

Nowhere is there an increase of checks from the left column to 
the right column. Either you were doing something not allowed to 
begin with (taking the address of a local in `@safe` code), or 
you were already in `@system` or `@trusted` code where `scope` 
isn't checked.

> I'm talking about needing @system and @trusted more in order to 
> avoid the compiler inferring anything as scope or giving me any 
> errors that relate to scope.

If you get an error with DIP1000 because of `scope`, you would 
have gotten an error without DIP1000 either way because you were 
taking the address of a local. DIP1000 is strictly not a breaking 
change.

> If DIP 1000 becomes the default, then the amount of @system 
> code in my programs will strictly increase, because I will use 
> @system and @trusted to avoid it entirely.

Again, DIP1000 doesn't do scope checks in `@system`/`@trusted` 
code, and won't introduce errors in code that was correctly 
`@safe` prior to DIP1000.

> It's trading @system for annotations

Not trading, but adding an alternative. You can still use 
`@system` to avoid DIP1000 checks.

> and I'm utterly sick of the number of annotations in typical D 
> code even when they're not hard to figure out
> (...) the time that I spent working on it just highlighted for 
> me that it was too much pain for too little gain, and I gave up.

I agree, and fully encourage you to not write `scope` attributes 
yourself. (I've spent a lot of time fixing wrong applications of 
`return` / `scope` attributes in druntime, Phobos, and certain 
dub projects.)

> I find that hard to believe, because once you start wrapping 
> types with scope member functions, you're going to end up with 
> cases where scope gets inferred, and then the code won't 
> compile if you pass it to something that isn't scope.

This is backwards. A `scope` parameter doesn't turn the argument 
into a `scope` value, if anything it removes `scope` from a 
value. (E.g. calling .dup on a scope array turns it into a 
non-scope array because dup's array parameter is `scope`).

Here's another table of scenarios of passinig arguments to a 
(scope) parameter:

| Parameter storage class:     | non-`scope` | `scope`   |
| ---------------------------- | ----------- | --------- |
| any argument in @system      | No error    | No error  |
| non-scope argument in @safe  | No error    | No error  |
| scope argument in @safe      | Error       | No error  |

A strict decrease in errors going to the right column.

> So, maybe I could point out places where it doesn't do what 
> it's supposed to if I spent a bunch of time trying to figure it 
> out, and it's likely that some of what I do understand about it 
> is wrong, but it seems to me that my time will be much better 
> served focusing on other things as long as DIP 1000 is not the 
> default

I'm completely sympathetic to you not wanting to spend effort 
reducing code to create DIP1000 bug reports, or refactoring your 
code to work with `scope` values. By all means, keep using 
`@trusted` / `@system` code for the few parts that use 
stack-allocated buffers in your code.

But please understand that unless you consider the current hole 
in `@safe` a feature, dip1000 by default will not break your 
code. If we disallow slicing local variables in `@safe` under 
`-preview=RobertsSimpleSafeD`, then that will break your codebase 
for real.

Once you fix your code to compile with 
`-preview=RobertsSimpleSafeD`, then switching to 
`-preview=dip1000` will not cause any breakage, or it is a bug.