On Monday, June 23, 2025 8:53:18 AM Mountain Daylight Time Dennis via 
Digitalmars-d-learn wrote:
> On Monday, 23 June 2025 at 10:37:58 UTC, Dom DiSc wrote:
> > I know, it would be needed to enable generic programming, but I
> > find a function that can take both an int and an int* suspect
> > anyway - this is kind of too generic for my taste.
>
> Would you say `HashMap!(Key, Value).opIndex(scope Key)` is too
> generic, and that `int[string]` and `int[int]` should have
> separate implementation code?
>
> I'm not against the compiler giving errors on no-op single
> attributes, but in some cases this can be complex for dmd's
> current implementation. For example, `pure T x;` has no effect
> unless T turns out to be a function type, which requires extra
> checks after `T` has been resolved. `scope` was internally
> removed from parameters by the compiler when the type had no
> pointers, but this caused forward reference errors:
>
> https://issues.dlang.org/show_bug.cgi?id=21667
>
> Giving an error on no-op `scope` attributes has the exact same
> problem.

There's also the issue of templated code. If an attribute is desirable in
the cases where it works, and it's fine for it to be ignored in the cases
where it doesn't apply, then that means that you can have code such as

    scope T foo;

or

    pure T foo;

without having to worry about whether the attribute works with a particular
T.

On the other hand, if it's an error for the attribute to be applied, then
the code will need to do something like use a static if to apply the
attribute, e.g.

    static if(isPointer!T || is(T == class) ||
              isDynamicArray!T || isAssociativeArray!T)
    {
        scope T foo;
    }
    else
        T foo;

and of course, if you get the check wrong, then the attribute won't be
applied properly.

So, if the attribute is no longer ignored, that will create certain classes
of problems that we don't currently have. It's a different set of problems
from the current situation, and it's debatable as to which situation is
better or worse, but it's nowhere near as straightforward as it first seems.

- Jonathan M Davis




  • scope parameter ... Neto via Digitalmars-d-learn
    • Re: scope p... Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn
      • Re: sco... Dom DiSc via Digitalmars-d-learn
        • Re:... user1234 via Digitalmars-d-learn
        • Re:... Dennis via Digitalmars-d-learn
          • ... Jonathan M Davis via Digitalmars-d-learn
          • ... Quirin Schroll via Digitalmars-d-learn
            • ... Jonathan M Davis via Digitalmars-d-learn

Reply via email to