Mitigating the attribute proliferation - attribute inference for functions

[via Digitalmars-d]

On Friday, 17 July 2015 at 12:43:33 UTC, Martin Nowak wrote:
> - 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.

As others have pointed out, it's an important semantic 
distinction. The performance gains (if any) are secondary.

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

Disagree here, too. Thread, process or module level is too 
coarse. @nogc as an attribute allows to avoid the GC on those 
levels, but can also be used in a much finer-grained way.

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

Agreed, that's probably unimportant.

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

Yes, definitely. Uniqueness is an important property, and we just 
don't utilize it properly yet. I believe what we have right now 
is barely the beginning.

>
> - @safe
>
>   Nice idea in theory, but why not do this as a compiler switch 
> for the
> modules being compiled (with an @unsafe {} guard).

Not sure I understand the part in parentheses. Likely, module 
level will be too coarse. Or do you mean we should have 
@safe-by-default, but only opt out of it with an @unsafe block, 
which however only works with a particular compiler switch? I 
don't see much use for such a switch.

(Of course, there are various other problems with the current 
concept and implementation.)

In general, I'm not sure why you choose to go the way of 
abolishing the attributes. Didn't you have a concept for 
inference that would mostly solve the problems?