On Wednesday, 27 May 2020 at 10:51:54 UTC, Walter Bright wrote:
On 5/27/2020 3:01 AM, Timon Gehr wrote:
I've addressed exactly this a dozen times or more, to you and
others. Repeating myself has become pointless.
It's fine to disagree with me. Argue that point. But don't say
I didn't address it.
I'm trying to understand the logic of "@safe by default for
extern declaration".
So I setup a simplified real-life example that I had in my mind...
Let's say we have a project consisting of:
- an ASM file containing several function definitions (assembly
language scares people away, so it's a good example).
- a .di file containing the extern(C) declarations of the former
ASM functions.
- and a .d file using those functions with @safe code.
No function is annotated.
Before DIP-1028, it compiles and link without annotations.
If extern(C) decl are @system by default, it will not compile
anymore, and a careless programmer will slap a "@trusted:" at the
top of the ".di" file (greenwashing), and it'll stay there.
On the other hand, a careful programmer will need to annotate
@trusted ONLY on functions that he actually trusts AND make the
project compile anyway (because he cannot afford to leave his
project broken). So what does he do to make it compile ? Should
he slap a "@trusted:" at the beginning of the file just like the
careless programmer and maybe explicitly annotate individually
declarations that are actually trusted ? It's weird...
However, if extern(C) decl are @safe by default, he does not need
to slap a "@trusted" at the top of the ".di" file, he just needs
to annotate individual declarations with @trusted to advertise
(to the QA, or his colleague or future self) that he reviewed
successfully the function implementation, AND it will still
compile.
So that example would go in favor of Walter's point. So is it a
good example? Does pinpoint the point?
Because again, as the others said, it's still controversial, it's
hard to sell, it's convoluted... I dunno...
