On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void whatevs(parameters);
Both require that whatevs() provide a safe interface. The
difference between them is in the implementation of those
functions, not the interface. Since the D compiler cannot see
those implementations, they are immaterial to the compiler and
user.
From my perspective, there is a clear difference in meaning
between them: @safe means verified by the compiler (which as you
mentioned can never be true for declarations where the code is
not available, hence it always is a lie in that case) and
@trusted means verified by the developer.
Whenever @trusted is slapped on _anything_, it is clear that
extra caution is needed (in codereviews etc.) and as others have
mentioned, it is easily searchable.
When I put @safe on a piece of code, my expectation is that it is
actually verified by the compiler. If that is not possible, it
should not compile.
The same reasoning also applies to the case where the annotations
are not added by the developer explicitly and the defaults are
used instead:
If the default is @safe and the code for an unannotated
declaration is not available, it should not compile.
Making @trusted the default is not an option because as mentioned
earlier, one of the points of @trusted is for it to be actually
seen, which is not the case if it is the default, so I will not
elaborate on that.
If @sytem is the default, there is no issue but of course the
whole point of this DIP is to move away from that.
I understand that today it is possible to slap @safe on
declarations without code without the compiler complaining but it
really _should_ be an error in order to have a consistent meaning
of @safe, @trusted and @system (@safe = compiler verified,
@trusted = user verified, @system = not verified) also in the
case of declarations where no code is available.
Let's assume this is indeed the way to go, then there are 2
possible solutions for this DIP regarding how to handle this:
1. Make declarations without code default to @system instead of
@safe. This is what many here have been arguing for but as you
mentioned several times, it has the drawback of adding special
cases to the language. As a user, it does not seem that
problematic though because the compiler can easily tell you what
is going on when there is an issue (i.e. calling an unannotated
declaration without code from a @safe function could result in
compiler error message that explains why this does not work). But
I admit that it is still a bit weird to have 2 different
defaults. Additionally, explicitly annotating such declarations
with @safe should be a compile error.
2. Make @safe the default for _all_ declarations but still make
@safe on declarations without code a compile error (because the
compiler cannot verify it). This means that annotating function
declarations without code with @system or @trusted is now
mandatory. This is what Timon has been arguing for if I
understood him correctly.
3. There may be a third option if we introduce something like
conditional safety but I do not completely understand that yet.
This is what H.S. Theo has been suggesting.
Option 1 and 2 both have the „issue“ that people might
„greenwash“ things by simply slapping @trusted: at the top of a
file. But that can always be done anyways and at least it is
explicit and searchable. As mentioned, using @trusted now has the
meaning that it is user verified so it always needs extra caution.
Personally I prefer option 2 because it is a lot more consistent:
There are no special cases.
Until now, I did not discuss whether or not all of this should
apply only to extern(C) function declarations without code or all
function declarations without code. This is because it is a
separate point. Both are possible and have pros and cons:
If it applies to extern(C) function declarations without code
only, then we can still have @safe extern(D) declarations. They
are not verified by the compiler but you get linker errors
instead because @safe is part of the mangling. The benefit is
that you get more @safe code by default, the drawback is that it
relies on linker errors instead of compiler errors and that it
introduces a special case.
If it applies to all function declarations without code, also
extern(D) function declarations without bodies need to be
annotated with @trusted explicitly if they are @safe or @trusted.
If they are @system, we still get linker errors due to name
mangling. The benefit is that it is a very consistent solution,
no special cases are needed. The drawback is that it requires
more manual effort to add the additional annotations (but then,
don't we want to encourage people to explicitly annotate things
anyways...?).
Personally, I prefer the second option because of its simplicity.
Also you mentioned somewhere that linker errors are not that
helpful to the user and I couldn’t agree more. Also I personally
don't use extern(D) function declarations without bodies a lot,
so the drawback is negligible for me. Others' experiences might
be different though.
Steven actually made a proposal regarding creating 2 different
manglings for extern(C) functions that are implemented in D.
Regardless of which of the solutions is taken, this could
provide the same benefits that we have for extern(D) functions
(linker errors if @safety does not match in the mangling).
However, it sounds like a complicated solution (in an answer to
him, you already mentioned that there might be technical
difficulties regarding some object formats, debugging symbols,
etc.) and I am not sure it's worth it. It also makes swapping out
the libraries a bit weird: if you use an actual C library, it
will always link but if swap to a library implemented in D, it
only links if the @saftey mangling matches.
Coming back to the original point: I think it is really important
that we give @safe, @trusted and @sytem their clear meaning (as
explained above) also for declarations without bodies. In my
opinion, we should choose the second option in both of the
questions I presented.
