On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
He can look at unattributed declarations.
The issue is, you have to know about that beforehand. In the other situation, you explicitly get warned by the compiler (by the compile error) that that something dangerous is going on.
Also, this means, there are now 2 different things to look for: @trusted function declarations and unannotated extern(C) declarations. The latter is much harder to search for (as Andrei also noted in his reply) and it's just much simpler to only have one escape hatch to look out for. It is also a very weird special case. @safe means no memory corruption is possible except for any @trusted declarations and any unannotated extern(C) declarations, wrongfully @safe extern(C) declarations and wrongfully @trusted extern(C) declarations. This just doesn’t sound right.
The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts.
The question should be rephrased: „Is explicit greenwashing by the developer better, more honest, more debuggable than implicit greenwashing by the compiler?“ Yes for better and more debuggable for the reasons that have already been mentioned so many times. Regarding honesty: In your variant, the compiler is dishonest, in the other variant, the developer is dishonest.
Just think about what the developer's reaction would be in the situation I described in my last post, when he actually finds the issue.
In your variant, the developer will be questioning why the compiler did not help him at all with realizing that there might be a problem. It is very likely that he blames the issue on the compiler.
In the other variant, he will realize that this something he had been warned about by the compiler and that he made a careless wrong decision and that it is his own fault. In the future he will be likely more careful when it comes to annotating stuff with @trusted. So this even has an educational effect.
