Am 08.02.2017 um 11:30 schrieb Kagamin:
On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
Keeping the system overloads would break the safety guarantees at a
relatively deep level and would render the whole effort rather useless
(this is the case for non-scope callbacks only, so if you stumble over
a deprecated function with a scope callback, then it should be fixed).
That's kind of intended: the system would inherit safety of the code it
calls. If the user code is not safe, there's no safety guarantee.
The problem is that there are two affected call stacks - the @system API
function that registers the @system callback, wrapping/casting it as
@trusted, and the event handler that later on actually calls the
callback. The latter place is where the hidden violation of the @safe
First, it actually has helped to detect some rather subtle issues in
the past that have gone unnoticed for a long time otherwise.
Being @safe-compatible and provide @safe guarantees are different
issues. The latter follows from the former if user code is @safe and
doesn't follow otherwise.
True, but that goes a bit beside my point. I was just arguing in favor
of the @safe system in general here, not about this particular instance.
And, maybe more importantly, annotating code as safe is the only way
to guarantee proper bounds checks, which is critical for a server
-boundscheck=on should do it, ldc provides even more control how code is
True, but that also imposes this restriction on all user code, while
just requiring -boundscheck=safeonly would enable dependent packages to
make a choice (aside from manually sidestepping boundschecks in code).
And finally, I feel that if nobody starts to embrace this on a broader
level now, it will never reach a truly mature state.
Fake @trusted annotations don't count as adoption of safety.
Pedantically speaking @safe loses its purpose if @trusted code is not
verified. Especially if fake @trusted becomes a habit. That's why safety
can't be forced and is opt-in.
I agree with the pedantic statement, but not with the conclusion. Right
now it's simply not possible in practice to write either fully compiler
checked code or fully audited trusted code on a large scale. But
starting to work towards a fully compiler checked code base makes all of
the missing spots visible, so that there is more pressure to actually
fix them. I was actually considering to open PRs for each instance, but
it quickly became clear that it were too many places for me to be able
to do that in a reasonable time frame (also, @trusted is still necessary
to support old compiler versions), so that had to be postponed.