Bug 19569 – overload resolution not right?

So, I understand we can overload on `nothrow` For instance, this works: void foo(); void foo() nothrow; void test() { foo(); } void test() nothrow { foo(); } But if `foo` take a template argument, it breaks down: void foo(T)(); void foo(T)() nothrow; void test() { foo!int(); } void test() nothrow { foo!int(); } > Error: called with argument types `()` matches both: > `foo!int.foo()` > and: > `foo!int.foo()` I feel like this is a bug...?

Attributes for templates are inferred. "void foo(T)();" will be inferred to be "nothrow" if the arguments are "nothrow". Attributes are not inferred for regular functions.

I'm not sure what you just said.

I mean, if there's not a really good reason those 2 pieces of code don't work the same, then they should work the same...

I think what Jacob is saying is that `nothrow` will be inferred for templates at the time of instantiation based on the context of the instatiation. That means you should not create both `void foo(T)()` and `void foo(T)() nothrow`. When the template is instantiated the compiler will automatically add `nothrow` to the instantiation if the context is `nothrow`. The bug here may be that the compiler allowed you to declare both a `nothrow` and non-`nothrow` template without error. I suppose it should be an error to add any inferred attribute to templates if they're going to inferred by the caller. Either that, or, if the user explicitly added an attribute to a template, then inference for that attribute should be disabled at the time of instantiation. I can't say I approve of this attribute inference behavior -- I'd prefer to have some mataprogramming facilities to control it -- but that's the way D currently seems to work, so changing it would probably require a DIP.

Still wrong. Consider: void foo()() { throw new Exception(""); } // Definitely not nothrow void foo()() nothrow { } // definitely is nothrow void test() { foo(); } void test() nothrow { foo(); } This gives the exact same error as before, demonstrating that this is indeed a problem exactly the way Manu describes it. However, if both variants of foo are indeed inferred to be nothrow, the criticisms presented by Jacob are correct. As for 'if the user explicitly added an attribute to a template, then inference for that attribute should be disabled at the time of instantiation.', consider this: void bar()() nothrow { throw new Exception(""); } unittest { bar(); } That gives the error message 'nothrow function bar!().bar may throw', so that already is disabled - if a templated function is marked nothrow, it has to abide by that promise.

> so changing it would probably require a DIP. Look at my example; any reasonable observer would say those cases should behave the same. I think it's objectively a bug, that shouldn't need a DIP...

> any reasonable observer would say those cases should behave the same. Here I have to disagree - both templates will be nothrow, so the compiler is correct to be confused. Look at my example above for a case where it's actually not ambiguous and still shows the same error message.

> both templates will be nothrow, so the compiler is correct to be confused. How can they both be nothrow? One is nothrow, the other is not... they're extern, so they can't infer anything. The instantiated templates should have identical signatures to the functions above. > Look at my example above for a case where it's actually not ambiguous and still shows the same error message. Right... but that's a bug, right? The 2 functions definitely have different (and correct) signatures, so the overload resolution should work just like the simple case?

> Right... but that's a bug, right? The 2 functions definitely have different (and correct) signatures, so the overload resolution should work just like the simple case? Absotively. I back you 100% in that this is a bug, and should absolutely not require a DIP in any form. > How can they both be nothrow? One is nothrow, the other is not... they're extern, so they can't infer anything. The instantiated templates should have identical signatures to the functions above. Ah, you're right - I forgot extern templates are a thing. For completion then, an example of how attributes are indeed not inferred for extern templates: void foo()(); void test() nothrow { foo(); // Error: function `foo!().foo` is not `nothrow` }

(In reply to Manu from comment #8) > How can they both be nothrow? One is nothrow, the other is not... they're > extern, so they can't infer anything. Oh, they don't have a body, I didn't think of that. Then I don't see how it could infer anything.

> So, I understand we can overload on `nothrow` I'm not aware that overloading on function attributes is possible. Do you have a reference in the specigfication?

I don't have a reference... I've just been doing it for years and assumed it was intended functionality. I mean, it's certainly necessary that we overload on const/immutable/shared/etc... so I figured the other attributes come naturally too.

> that we overload on const/immutable/shared These are type modifiers for 'this', so they are different.

Well either way, it seems to work and I've been using it for years.

Can you show an example? The one above does not: https://run.dlang.io/is/JCgWPp

Oh wow... interesting. I think I have broken code floating around :/ So, is the issue here that it's possible to emit 2 functions that have ambiguous distinction, but no compile error? If a nothrow function can call either one, then it probably shouldn't just pick one, but rather emit an ambiguous call error instead?

@look-at-me created dlang/dmd pull request #9406 "[Reg 2.074.1] Fix Issue 19569 Fixed overload resolution giving priority to covariants when should be ambiguous." fixing this issue: - Fix Issue 19569 Fixed overload resolution giving priority to covariants when should be ambiguous. https://github.com/dlang/dmd/pull/9406

(In reply to Manu from comment #16) > Oh wow... interesting. > I think I have broken code floating around :/ > > So, is the issue here that it's possible to emit 2 functions that have > ambiguous distinction, but no compile error? > If a nothrow function can call either one, then it probably shouldn't just > pick one, but rather emit an ambiguous call error instead? But it doesn't pick one randomly, it picks the "better one" which is the one that is pure/@safe/nothrow/@nogc

dlang/dmd pull request #9406 "[Reg 2.074.1] Fix Issue 19569 Fixed overload resolution giving priority to covariants when should be ambiguous." was merged into master: - 3e29f1141b76aa087eab2dc917bd250174560abd by look-at-me: Fix Issue 19569 Fixed overload resolution giving priority to covariants when should be ambiguous. https://github.com/dlang/dmd/pull/9406