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?
