On 23/5/20 20:40, Johannes T wrote:
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[..]
Thank you for the detailed and insightful explanation.
Would it be feasible to have a follow-up DIP that enables implicit
@system extern as an opt-in (e.g. -nosafeextern). The frustration most
people seem to have with @safe extern is that it lessens the promise of
@safe without a recourse.
Also there will need to be an answer to this probably inthe future not
unusual question:
My code is 100% @safe, there's no @trusted block anywhere, why am I
getting memory corruption?
To me the expectation / promise was that @safe code was safe from memory
corruption modulo bugs in the implementation.
The only source for issues would be then @trusted code that could be
audited as needed.
You could say "well, you always had to check for those", but the
difference is that until now the compiler would shout at me if I didn't,
so I wouldn't forget about them.
Now it has to be clearly explained that you should check for @trusted
code AND unmarked external C functions.
