DIP1000 observation

[Jonathan M Davis]

On Tuesday, August 27, 2024 4:51:26 AM MDT Dennis via Digitalmars-d wrote:
> On Monday, 26 August 2024 at 23:37:36 UTC, Jonathan M Davis wrote:
> > 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?

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. 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 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.

I am perfectly fine with the status quo of taking the address of local
variables being treated as @system, and I don't want to have to mark up any
code with scope in order to try to make it @safe. When I did try to deal
with DIP 1000, it was too hard to figure out what was going on, and it's
simply not solving a problem that I feel needs to be solved.

Right now, taking the address of a local variable results in a very small
amount of code being affected, whereas any attempt to have the compiler
verify with scope that it's not escaping then requires using scope on all of
the places where that pointer or slice is used. It's trading @system for
annotations, and I'm utterly sick of the number of annotations in typical D
code even when they're not hard to figure out, and with the changes that DIP
1000 adds, scope is way too hard to figure out. Since you've been spending a
lot of time and effort working on it, you probably do understand it quite
well, but 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.

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

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. If that just gets inferred as @system, and the calling code
isn't explictly marked as @safe, then maybe there won't be compilation
errors, but it was scope inferrence that made me give up on figuring out how
to make dxml compile with DIP 1000. It doesn't use scope anywhere and IMHO
shouldn't need it, but scope was being inferred on some basis (presumably
due to some tests that slice static arrays, since the XML parsing itself
doesn't do anything of the sort). It was not obvious how to fix it, and it
was complaining about stuff that wasn't actually a problem.

> 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.

Honestly, I found DIP 1000 hard enough to understand that I gave up on it,
and I'm just not willing to spend the time and energy to figure it out at
this point. Even if the basic idea is simple, the sum total of it is not
even vaguely simple, and it's trying to solve a problem that I simply don't
have.

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 and then figuring out how to completely avoid it if it
ever does become the default. It's just too much complexity in an already
complex language.

Honestly, if I were making annotation-related changes to D, I would be
removing some of the attributes that we already have in order to simplify
things. I would not be looking to add more, which is essentially what DIP
1000 is doing even if scope technically already exists in the language.

- Jonathan M Davis