DIP1028 - Rationale for accepting as is

[Johannes Loher]

Am 26.05.20 um 14:20 schrieb Johannes T:
> Thank you very much for your patience with all the negative feedback. I
> get your decision to not annotate extern C with @system by default.

As much as i disagree with the decision, I am still very glad that we
are at least having a discussion. I also want to thank Walter for
participating here. I understand this can be difficult but it is the
right thing to do.

> The biggest issue with extern @system is that @trusted would become less
> useful when dealing with declarations and bindings. @trusted would
> appear more frequently. We wouldn't be able to assume that the author
> put in effort in assessing the trustworthiness of a declaration. More
> greenwashing, less safety. Those are severe drawbacks, I agree.
> However, as Andrei pointed out, PR is a huge problem. We need to be able
> to sell it with a straight face.
> I think this might be done by formally redefining the meaning of safety
> attributes when applied to extern:
> The safety of extern can't be assessed by the compiler. Implicit "@safe"
> extern within @safe code is accepted for the convenience of the average
> user. Explicit @system or @trusted can be added for desired behavior.
> I think this can be explained.

Well, the spec actually already mentions that:

> Safe External Functions
>
> External functions don't have a function body visible to the compiler:
>
> @safe extern (C) void play();
>
> and so safety cannot be verified automatically.
> Best Practices: Explicitly set an attribute for external functions
rather than relying on default settings.

I still don't think this is the correct thing to do. Instead, annotating
external (at least extern(C)) functions with @safe (implicitly as the
default or explicitly) should be a compile error in my opinion.

> It's not an acceptable solution for people who require correctness.
> ZombineDev can't tell an auditor that he relies on D-Scanner to find the
> problematic spots. I believe it's unavoidable to provide an option to
> change the default. It could make extern @system or refuse to compile
> safe code calling @safe extern.

A switch might help but the whole purpose of this DIP is to get the
defaults right. In my opinion, such a switch should be enabled by
default. There is also the danger of creating 2 versions of the language
that are incompatible with each other. Only giving this a quick thought,
I believe it could work (you can still link libraries compiled with and
without the switch) but I'm not completely sure.