https://issues.dlang.org/show_bug.cgi?id=23941

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
Looks like the problem is in the argumentMatchParameter function, which doesn't check for scope parameters.

But I'm a bit concerned that changing this may mess up scope inference, which occurs after an overload is selected. Changing this may destabilize the language.

I'm also skeptical of the utility of overloading based on `scope`. Maybe this pattern just doesn't make sense.

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
I'm strongly leaning towards simply documenting that `scope` does not affect overloading.

The spec https://dlang.org/spec/function.html#function-overloading doesn't say anything about scope, which should be fixed.

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #3 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
But that's a problem with the compiler, not the language, right? There's nothing fundamental stopping someone from writing a D compiler that correctly allows this?

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Vladimir Panteleev from comment #3)
> But that's a problem with the compiler, not the language, right? There's nothing fundamental stopping someone from writing a D compiler that correctly allows this?

It is a language problem. The dip1000 rules were designed as a layer that adds extra protections. But when they start changing the way overloading works, then they are changing the behavior. At some point, we lose our grip on how the language works.

This is especially true since the language allows inference of scope attributes. When does the inference happen, and how does that interact with overloading?

I really hate to get lost in a swamp over this. When we designed 'alias this', we wound up lost in a swamp of having little idea how to resolve interactions with other features in a principled way. It worked fine in isolation, but not when mixed with inheritance.

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
I was going to mark it an 'Enhancement', but looks like you've already done so. We seem to be in at least some agreement!

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #6 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
I don't think there is any disagreement at all. Thank you for the explanation, that's very interesting.

FWIW, I tried using scope overloads to solve the "function which only sometimes needs to make a copy" problem. The scope overload needs to call .dup, but the non-scope overload never needs to call .dup, because lack of scope implies infinite lifetime.

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
See https://github.com/dlang/dlang.org/pull/3648 to fix the documentation.

--

https://issues.dlang.org/show_bug.cgi?id=23941

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--

https://issues.dlang.org/show_bug.cgi?id=23941

--- Comment #8 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
Is there a better solution to the "function which only sometimes needs to make a copy" problem?

--