What is the current state of scope and member functions?

[Jonathan M Davis]

On Tuesday, September 12, 2023 4:48:13 AM MDT Dennis via Digitalmars-d wrote:
> On Tuesday, 12 September 2023 at 09:52:58 UTC, Jonathan M Davis
>
> wrote:
> > and my gut reaction is that it would be better to just slap
> > @trusted in a bunch of places to shut the compiler up about
> > scope than it would be to try to actually make it work - though
> > unfortunately, that's not going to work very well with
> > templated code (particularly in libraries), which is precisely
> > where I'm seeing the compiler complain about scope even though
> > I'm not doing stuff like taking the address of local variables.
>
> Please file a bug when you get lifetime errors while not taking
> the address of a local. Note that slicing a local static array is
> taking the address, and it being allowed in @safe code without
> dip1000 is a long standing accepts-invalid bug. dip1000 is
> strictly allowing more code to compile, and all the breakage
> comes from the accepts-invalid bug. Robert's DConf '23 proposal
> to simplify by disallowing @safe code slicing local static arrays
> altogether  strictly breaks more code.

IMHO, the big mistake was making static arrays implicitly convert to dynamic
arrays. Being able to slice them to get dynamic arrays is fine, but
automatically slicing them is a lot like automatically taking the address of
a local variable to get an implicit conversion to a pointer. The need for
scope would go down considerably if such conversions weren't happening in an
essentially invisible manner, and the programmer was required to explicitly
slice a static array to get a dynamic array just like they're required to
explicitly take the address of a local variable to get a pointer.
Unfortunately, Walter didn't agree with that idea (probably in large part
because it would have required deprecating existing behavior), so instead of
fixing it and reducing the need for something like scope, we got DIP 1000
instead.

In general, I'm not in favor of being as extreme as Robert was proposing
with regards to removing stuff from @safe, but DIP 1000 seems like a pretty
extreme set of changes to solve a fairly small problem that most D
programmers who aren't constantly interacting with C code should only rarely
need to worry about. Simply getting rid of the implicit conversion from
static arrays to dynamic arrays would go a _long_ way IMHO.

As for reporting stuff, I will if I can, but even figuring out what's
supposed to be happening - particularly in highly templated code - can be
difficult if you're not really well-versed in exactly how scope is supposed
to work right now. scope seems to have become very complicated in the search
to make more and more code work with it, thus reducing the need for
@trusted, instead of just requiring that the programmer use @trusted when
taking the address of a local (or slicing a static array) and then letting
them make sure that they're doing it right. I can appreciate the sentiment
and goal behind scope, but the more I deal with it, the more it seems like
it's a nuke trying to take out an ant. At the moment, I'm inclined to
believe that it adds _way_ too much complication to the language for minimal
benefit.

Quite possibly the biggest design smell with regards to scope is return
scope and how the order and adjacency of the attributes changes the
semantics. Almost no one is going to remember that kind of thing. But scope
has become ridiculously complicated in general. And honestly, as things
stand, if DIP 1000 were enabled by default, I would probably stop using
@safe entirely just to save myself the headaches that scope introduces - or
at least, I'd stop using it whenever the compiler complained about scope.

> As for removing the scope-stripping of member functions, I
> remember I tried that, but failed because it would break code in
> an unexpected way (forward references again):
>
> https://github.com/dlang/dmd/pull/14232#issuecomment-1162906573

Well, I certainly don't know what is going to be possible on the
implementation side of things, but every inconsistency that's added to
scope's design is going to make it harder to understand. And if it's too
hard to understand, most people will just avoid it rather than benefiting
from the feature. So, if inconsistencise can reasonably be removed, they
should be.

- Jonathan M Davis