Mitigating the attribute proliferation - attribute inference for functions

[Kagamin via Digitalmars-d]

On Friday, 17 July 2015 at 12:43:33 UTC, Martin Nowak wrote:
> The assumption that code with attributes is better than code 
> without attributes is flawed.
>
> - nothrow
>
>   Nice, the compiler must not emit exception handling code, but 
> the real
> problem is how bad dmd's EH code is.
> https://issues.dlang.org/show_bug.cgi?id=12442
>   State of the art EH handling is almost "zero cost", 
> particularly if
> compared to other error handling schemes.

nothrow is not only performance, but also semantics.
Yeah, an optimization was planned to not run cleanups on Error, 
without it you can't inline cleanups, and nothrow functions can 
throw Errors.

> - @nogc
>
>   Why is this needed on a per function level? If one doesn't 
> want to use
> the GC it could be disabled on a per-thread or per-process 
> level.
>   We now have a GC profiler, which is a good tool to find 
> unwanted
> allocations.
>   Of course we need to change many phobos functions to avoid
> allocations, but @nogc doesn't help us to design better APIs.

Hmm, it sounds interesting to make @nogc a language option 
instead of function attribute.

> - pure
>
>   The compiler can reuse the result of a strongly pure function 
> call,
>   but compilers can do CSE [¹] for ages. CSE requires inlining 
> to determine
>   whether a function has a sideeffect, but reusing of results 
> is almost
> exclusively useful for functions that are small enough to be 
> inlined anyhow.

You don't always have the source for the function, and currently 
purity needs only the function signature alone. Also a function 
attribute allows to enforce purity.

> - @safe
>
>   Nice idea in theory, but why not do this as a compiler switch 
> for the
> modules being compiled (with an @unsafe {} guard).
>   The way we do it currently with @trusted/@safe doesn't 
> guarantee
> anything for @trusted/@safe foreign code anyhow.

You mean SafeD allows unsafe code?