Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 09:42:19 UTC, Daniel N wrote:
> FYI, I wrote an enhancement request for this already. In case 
> the discussion reaches a conclusion this time around, you might 
> want to update the status:
>
> https://issues.dlang.org/show_bug.cgi?id=13567

Oh great, can you help me to turn this into a DIP?
We need to define a sane behavior for when public templates call 
private functions.

One idea I'm carrying around for some time is the following.
For functions with inferred attributes the compiler could emit an 
additional alias symbol with the mangling of the function before 
the inference.
That would allow to link against that function without running 
inference and still use inference for the same function 
internally.
Note that this relies on covariant attributes, i.e.
    void foo() @safe @nogc pure nothrow
is implicitly convertible to
    void foo()

This could work out quite well, you only need to add attributes 
to your private functions to support public templates, but 
typically this should only be few entry points of your library.

One problem arising from that is testing your API.

----
void tmpl(T)(T t) { return func(t.foo); }
private void func(size_t v) { return v; }

unittest @safe @nogc pure nothrow
{
     static struct S { size_t foo; }
     tmpl(S()); // works here, but not outside of this module
}
----