DIP1028 - Rationale for accepting as is

[Arafel]

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.