The point of @safe by default for C declarations was:

1. so that we would not be deluged with complaints about breaking existing code

2. so people would use it

What people *will* do with C unsafe by default is:

1. slap `@trusted:` at the beginning and go on their merry way, and nothing was accomplished except annoying people

On Wednesday, 8 June 2022 at 23:24:35 UTC, Walter Bright wrote:
> On 6/8/2022 9:22 AM, Steven Schveighoffer wrote:
>> The reality is that people are (mostly) only dealing with the existing implementation, until it stops working. But to silently break it, and silently break it with *memory corruption* does not seem an appropriate penalty.
>
> The point of @system code is people can do whatever they want.
>
> The answer is to make @safe the default. But that DIP was rejected.

Because contrary to Ada, .NET, Rust, Go, Swift,.... it considered calling into C "safe".

On Thursday, 9 June 2022 at 00:04:07 UTC, Mathias LANG wrote:
> On Wednesday, 8 June 2022 at 23:35:03 UTC, Walter Bright wrote:
>> On 6/8/2022 12:59 PM, Mathias LANG wrote:
>>> I have argued with Walter for a long time that having `scope` enforced only in `@safe` code was a grave mistake, and would be extremely confusing. It would have avoided this situation.
>>
>> The idea is that @safe should be the default and so @system code would be rare and would stick out like a sore thumb.
>>
>> In @system code, maintaining the invariants of the function parameters is entirely up to the programmer.
>
> `@safe` by default is only viable if `@safe` has minimum to no friction.
> This isn't the case *at all*. We have examples in the standard library itself.
>
> It's also departing from D's identity as a system programming language which makes it trivial to interop with C / C++, alienating a sizeable portion of our community in the process.

Swift, Ada, Modula-2, Modula-3, Rust, to pick only examples of languages that have an acknoledged identity as systems programming languages, had no issue considering calls into C and C++ unsafe.

Three of them have more users in 2022 than D can ever aspire by current trends.

On Thursday, 9 June 2022 at 00:34:51 UTC, forkit wrote:
> On Thursday, 9 June 2022 at 00:04:07 UTC, Mathias LANG wrote:
>>
>> `@safe` by default is only viable if `@safe` has minimum to no friction.
>> This isn't the case *at all*. We have examples in the standard library itself.
>>
>> It's also departing from D's identity as a system programming language which makes it trivial to interop with C / C++, alienating a sizeable portion of our community in the process.
>
> It does seem to me, that there is greater move towards memory safety 'by default', and not away from it.
>
> Rust has demonstrated, that this is not antithetical to systems programming.
>
> Unsafe is always available when it's required.
>
> But yes, certainly, @safe needs a lot more work for it to ever be considered as a default in D. I have it as default in every module I create. I usually have to end up commenting it out, even for simple things.
>
> But IMO, in programming, one should be moving towards being explicit about being unsafe, rather than being safe.
>
> Those who are truly alienated by such an idea, have C/C++ ;-)

Fun historical fact, the first languages to have unsafe code blocks date back to early 60's, late 50's, JOVIAL and ESPOL (superseded by NEWP). NEWP is still used in production, on ClearPath MCP mainframes sold by Unisys, and I wouldn't be surprised if US army wouldn't have some stuff running JOVIAL.

On Thursday, 9 June 2022 at 06:53:55 UTC, Walter Bright wrote:
> The point of @safe by default for C declarations was:
>
> 1. so that we would not be deluged with complaints about breaking existing code
>
> 2. so people would use it
>
> What people *will* do with C unsafe by default is:
>
> 1. slap `@trusted:` at the beginning and go on their merry way, and nothing was accomplished except annoying people

Still, slapping @trusted is explicit and greppable, and so can get flagged by a simple script even before reviewed by a human.

Also, once ImportC becomes the default way of interfacing to C APIs, their memory safety attributes are under compiler control and circumventing that would require extra effort.

On Thursday, 9 June 2022 at 06:53:55 UTC, Walter Bright wrote:
> The point of @safe by default for C declarations was:
>
> 1. so that we would not be deluged with complaints about breaking existing code
>
> 2. so people would use it
>
> What people *will* do with C unsafe by default is:
>
> 1. slap `@trusted:` at the beginning and go on their merry way, and nothing was accomplished except annoying people

As said during the infinitely long thread about that in the past, rejecting a slapped '@trusted:' is work for code reviewers if your company minds for safety.

But please, not again that discussion.
(said that, if there was a -preview with @safe-as-default but @system extern(C) that will become the default in our codebase)

On Thursday, 9 June 2022 at 06:53:55 UTC, Walter Bright wrote:
> The point of @safe by default for C declarations was:
>
> 1. so that we would not be deluged with complaints about breaking existing code
>
> 2. so people would use it
>
> What people *will* do with C unsafe by default is:
>
> 1. slap `@trusted:` at the beginning and go on their merry way, and nothing was accomplished except annoying people

That is their fault and provides a clear warning sign of where to look to fix the problem and improve safety. grepping for trusted is the number 1 way to find starting points for memory safety problems (aside from gdb/asan)

On 09.06.22 08:46, Walter Bright wrote:
> On 6/8/2022 5:38 PM, Timon Gehr wrote:
>> This does not have anything to do with `@safe` by default, it's just an inconsistency in the compiler implementation.
> 
> I could make a case for every one of the safety checks being checked in @system code, too.
> ...

No. You really would not be able to. The point of `@safe` is to catch everything that's bad. The point of `@system` is to allow everything that makes sense.

If the compiler can't figure out if something is fine, it should be an error in `@safe` code and allowed in `@system`.

But if the compiler can easily tell that something makes no sense, it should still be an error in both `@safe` and `@system` code!

> The existing checks you note were there long before @safe/@trusted/@system was added. Them remaining is an artifact of evolution and a wish to support legacy behavior.

It's a pity you feel this way. Clearly if something is _always wrong_ it makes sense to have a diagnostic. There is type checking in `@system` code, and that makes sense. E.g., we don't just make accessing an undefined identifier in `@system` code UB, because that would be ridiculous.

On Wednesday, 8 June 2022 at 23:29:53 UTC, Walter Bright wrote:
> On 6/8/2022 12:33 PM, 12345swordy wrote:
>> You shouldn't have to mark your functions safe to prevent shooting yourself in the foot.
>
> I agree, but the DIP to make functions @safe by default was rejected.

Because it contained “assume all C code is @safe unless explicitly marked otherwise”, which is pretty wild!