Mitigating the attribute proliferation - attribute inference for functions

[Dmitry Olshansky via Digitalmars-d]

On 17-Jul-2015 15:43, Martin Nowak wrote:
> I have to bring this up again, b/c I consider the heavy investment in
> attributes one of the worst decisions lately.
>
> It's very very hard and time consuming to write attribute correct code.

For sure. Personally I ignore all but pure and nothrow. Not in Phobos 
however...

[snip]

> =================== Attributes are hardly useful ======================
>
> The assumption that code with attributes is better than code without
> attributes is flawed.
>

> - @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.
>

Agreed. Not only no-allocation crowd had expressed the concern in going 
only @nogc but not @noheap route but it's pretty redundant compared to 
all the other tools and niche enough to not bring much to the table.

 > - @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.

`@safe` is still both poorly specified (on exception rather then 
allowance basis) and leaves a lot to be desired w.r.t. trusted blocks in 
otherwise safe code.

Not to mention the unfortunate interplay with templates where you need 
an unsafe operation but don't want to blindly accept potential unsafety 
of the user-defined type itself.

 > - 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.

There is huge value in this. Even C++ choose to add noexcept into 
otherwise exteramly complicated language.

nothrow is all about semnatics not only performance, e.g. I can write 
tryivial exception-safe code if I choose to accept only nothrow callbacks.

> - 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.

CSE is cool but need something both simpler and working with binary 
libraries and separate compilation.

>    The result of a strongly pure functions has unique ownership and can
> be implicitly cast to immutable. Nice insight, but is that any good?
>

pure and nothrow actually about the only ones bringing the benefit to 
outweight the cost I esp. like how immutable + pure goes nicely with FP 
classics.


-- 
Dmitry Olshansky