DIP1000 observation

[Jonathan M Davis]

On Monday, August 26, 2024 12:39:54 PM MDT Dennis via Digitalmars-d wrote:
> On Monday, 26 August 2024 at 10:56:06 UTC, Jonathan M Davis wrote:
> > and if I mark up any code as scope to make the compiler happy,
> > that quickly becomes viral, whereas right now, I can just take
> > the address of a local and happily pass it around without any
> > complaints. I just have to mark the function as @trusted
> > (...)
> > But using DIP 1000 means that scope has to be used all over the
> > place.
>
> No need! Even with dip1000, you can pass scope values to
> non-scope parameters in `@system` or `@trusted` functions:
>
> ```D
> void f(char[] str) @safe; // parameter `str` is not marked `scope`
>
> void g() @trusted // checking stack pointer lifetimes manually
> here
> {
>      char[32] str;
>      f(str[]);
> }
> ```
>
> The scopeness of `str[]` ends then and there, no viral
> application of `scope` needed.

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. For my own libraries, I'd likely just tell them to
cast away scope, but it does add yet another attributes issue where some
libraries are going to support it and some won't. And the problem will be
worse with templated code - particularly if user-defined types get involved,
and they have scope member functions. 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.

As long as you're doing some really basic stuff with pointers and arrays,
maybe what DIP 1000 does with scope is restricted enough to be sane, but the
problem pretty much has to balloon once you bring user-defined types into
the mix - particularly with templated code. Certainly, it was issues with
user-defined types and member functions that made me give up on going to the
effort of making dxml use DIP 1000 and instead hope that we'd eventually
decide to do something other than DIP 1000 which wasn't so hard to figure
out and use.

And honestly, if @system and @trusted functions can accept scope data
without having to cast away scope, that will probably just increase how much
I use @system instead of @safe and overall result in more memory safety
issues in my code, whereas right now, the issues that DIP 1000 is looking to
help with are pretty rare in my code, since the cases where I take the
address of a local or slice a static array are pretty restricted.

But I'm sure that I'll figure out how to make things work with code that I
write for myself or other code where I'm dealing with a relatively small
number of people who can all get on the same page about what to do about
attributes in a particular code base. Ultimately, I expect that the bigger
problem is going to be libraries, since they have to deal with users'
choices with regards to scope and memory safety.

- Jonathan M Davis