What is the current state of scope and member functions?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sun Sep 10 21:23:06 UTC 2023


It is my understanding that with the changes for DIP 1000, scope now applies
to member functions, in which case, it marks the implicit this parameter as
scope. And I get deprecation messages in some of my code complaining about
stuff like popFront on a range type not being scope, which would seem to
indicate that scope does indeed now apply to member functions. However, I
don't seem to be getting any inference for it. For instance, this very
simple example does not compile:

void main()
{
    import std.traits;
    static assert(functionAttributes!(Range!int.popFront) &
                  FunctionAttribute.scope_);
}

struct Range(T)
{
    void popFront()
    {
    }
}

The member function is templated (because the type is templated), and it
does literally nothing, so I would expect scope to be inferred, but it
clearly isn't. To make matters even weirder, if I explicitly put scope on
popFront, it _still_ fails to compile. And printing out the function's type
gives

pure nothrow @nogc @safe void()

in both cases, so this doesn't seem to be a problem with std.traits or my
usage of it. Rather, it seems to indicate that not only is scope not being
inferred for popFront, but it's being outright ignored when it's used
explicitly. This would imply that scope is _not_ supposed to be used on
member functions.

And whether I use -preview=dip1000 seems to have no effect on this
particular example. scope is not inferred if it isn't explicitly there, and
it's ignored if it is explicitly there.

So, am I misunderstanding something about how scope is supposed to work, and
it's not supposed be used on member functions? And if that's the case, why
am I getting deprecation messages about member functions not being scope
within an @safe function? Or is this a compiler bug that needs fixing?

- Jonathan M Davis





More information about the Digitalmars-d mailing list