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
