Bug 9511 – [enh] overloading on attributes

void foo() @safe { } void foo() nothrow { } void bar() @safe { foo(); } void bar() nothrow { foo(); } ---- This currently fails, because foo() is said to match both functions, but at the same time it is not an error to declare the overloads. The enhancement is to use attribute sets to resolve overloads. - The attribute set of the caller must be a subset of the callee. - The attribute sets of overloads must be disjoint if they have the same signature otherwise. ---- Some C++ AMP work has been done on this topic for restrict overloading. http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/29/function-overloading-with-restrict-in-c-amp.aspx

I don't think that it's going to work to overload on any of these attributes. They're inferred for templated functions, which means that the functions being used within a function must have their @safety, purety, and nothrow-ity determined before they're determined for the function itself. So, you can't reasonably determine an overload of nothrow, @safe, or pure based on the caller. It has to be based on the arguments (which is _always_ how function overloading is determined). Rather, it would be better to make it so that overloads with the same parameters are illegal.

> They're inferred for templated functions Right, I didn't thought of inference. But couldn't it still work with the non-inferred original type.

> Rather, it would be better to make it so that overloads with the same parameters are illegal. Yes, that would be one solution, but I do think this could come in handy with UDA.

Sometimes tag dispatching is used for the same purpose but it's not automated and definitely looses covariance. http://www.boost.org/community/generic_programming.html#tag_dispatching

Jacob Carlborg and Andrei found the talk/article I was searching when I opened this enhancement. http://www.artima.com/cppsource/codefeaturesP.html It was mentioned here while talking about using UDA to guarantee non-allocating functions. http://forum.dlang.org/post/[email protected]

I think we can safely close this as WONTFIX. Having a distinction between functions that have their attributes inferred and functions that don't complicates the language for a minor benefit.