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

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

-boundscheck=on should do it, ldc provides even more control how code is
compiled.

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.

Reply via email to