On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
> On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
>> On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
>>> On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
>>>> [...]
>>>
>>> The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.j
>>
>> Completely agree but my above says nothing about @trusted.
>>
>>>
>>>> [...]
>>>
>>> The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits.
>>
>> Another distinction: pre 1028 your compilation will error out.
>>  Post 1028 it will not.
>
> Quite the opposite. Most code out there isn't marked as @safe/@trusted/@system. If I add a dub dependency and don't bother with @safe, I can call anything, in any way. Post 1028... nope. Unmarked @system function definitions themselves won't compile.

I think I see the difficulty.  We both support 1028's elimination of the "I can call anything, in any way" default.  I really like @safe by default for machine checkable code.  I don't support @safe by default for extern C.

On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
> On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
>> On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
>>> On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
>>>> On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
>>>>
>>>> @safe: the compiler checks
>>>
>>> The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.j
>>
>> Completely agree but my above says nothing about @trusted.
>>
>>>
>>>> @safe post 1028: the compiler checks, sometimes, just not in the scary parts
>>>
>>> The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits.
>>
>> Another distinction: pre 1028 your compilation will error out.
>>  Post 1028 it will not.
>
> Quite the opposite. Most code out there isn't marked as @safe/@trusted/@system. If I add a dub dependency and don't bother with @safe, I can call anything, in any way. Post 1028... nope. Unmarked @system function definitions themselves won't compile.

Which will just lead people to pure @trusted: at the top of their code to get it to compile again, with or without extern(C) being @safe by default. Then someone that uses it as dependency will mistaken think it is @safe. What's to stop this kind of "greenwashing" and why is greenwashing only important to prevent when talking about extern(C) but every other code that will break from this change?

On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
> On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
>> On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
>>> On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
>>>
>>> @safe: the compiler checks
>>
>> The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.
>
> Completely agree but my above says nothing about @trusted.

But it matters. Even if your code is @safe, that doesn't mean it is completely safe. Your @safe code can call into somebody else's @safe code that can call @trusted code that calls @system code. If you want to guarantee that your code is safe, you'll have to find and audit the @trusted bits (as well as everything that is called from there).

If extern(C) is implicitly @system, you'll have to make calls @trusted and they are subject to auditing. If extern(C) is implicitly @safe, calls are still subject to auditing. Whatever your preference, I think the compiler can be of greater help in finding the bits that require auditing than grep can, and then the difference isn't all that important anymore. Safe wrappers around C libraries are still written the same way, audited the same way, and unsafe calls into C caught the same way.

I agree that making extern(!D) @system looks sound, like the way it should be. But it breaks compilation of existing code, and it is too easy to evade by slapping on an explicit @trusted or (God forbid) @safe. Or we could make extern(!D) to be anything other than @system an error, which would be really annoying. I think that what we all strive for is to reduce the strain of coding as well as to reduce the strain of auditing.

-- Bastiaan.

On Tuesday, 26 May 2020 at 18:06:00 UTC, Bastiaan Veelo wrote:
> On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
>> On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
>>> On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
>>>> On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
>>>>
>>>> @safe: the compiler checks
>>>
>>> The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.
>>
>> Completely agree but my above says nothing about @trusted.
>
> But it matters. Even if your code is @safe, that doesn't mean it is completely safe. Your @safe code can call into somebody else's @safe code that can call @trusted code that calls @system code. If you want to guarantee that your code is safe, you'll have to find and audit the @trusted bits (as well as everything that is called from there).

Agree that the transitive closure is difficult, especially for humans.

>
> If extern(C) is implicitly @system, you'll have to make calls @trusted and they are subject to auditing. If extern(C) is implicitly @safe, calls are still subject to auditing. Whatever your preference, I think the compiler can be of greater help in finding the bits that require auditing than grep can, and then the difference isn't all that important anymore. Safe wrappers around C libraries are still written the same way, audited the same way, and unsafe calls into C caught the same way.

Agree.  @trusted doesn't mean that the code so labelled should be blindly trusted.  The aim should be reduction of @trusted where practical.  Silently letting all extern C functions inside the tent is not a reduction.

>
> I agree that making extern(!D) @system looks sound, like the way it should be. But it breaks compilation of existing code, and it is too easy to evade by slapping on an explicit @trusted or (God forbid) @safe. Or we could make extern(!D) to be anything other than @system an error, which would be really annoying. I think that what we all strive for is to reduce the strain of coding as well as to reduce the strain of auditing.

I'm all for reducing the strain of writing correct code.

As others have implied, we're dealing with, at least, two issues here: 1) any transition from opt-in to opt-out safety will break code.  Some programmers will resort to greenwashing in an effort to "fix" it.  Will we be better off post transition? And 2) should uncheckable code be considered @safe, ever.

On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
> Which will just lead people to pure @trusted: at the top of their code to get it to compile again, with or without extern(C) being @safe by default. Then someone that uses it as dependency will mistaken think it is @safe. What's to stop this kind of "greenwashing" and why is greenwashing only important to prevent when talking about extern(C) but every other code that will break from this change?

The reason extern function declarations are particularly problematic is that changing them from @system-by-default to @safe-by-default can cause *silent* breakage in existing, correct code. By "silent", I mean that there is no message from the compiler warning you that the memory safety of the code has been compromised. It will still compile, and you will only find out that something has gone wrong when you run into memory corruption at run-time.

This undermines the entire purpose of @safe, which is to automatically catch code with potential memory errors at compile time.

On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote:
> Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked.  Post 1028, IIUC, the compilation will go through without complaint.  This seems quite clear.  What am I missing?

I agree that being forced to think about a trusted interface to that routine can contribute to safety. Not getting this is the price if DIP 1028 as is. Doing it the other way bears a different price.

Still, it does not change the amount of code that must be vetted during an audit, either way.

-- Bastiaan.

On Tuesday, 26 May 2020 at 20:38:17 UTC, Bastiaan Veelo wrote:
> On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote:
>> Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked.  Post 1028, IIUC, the compilation will go through without complaint.  This seems quite clear.  What am I missing?
>
> I agree that being forced to think about a trusted interface to that routine can contribute to safety. Not getting this is the price if DIP 1028 as is. Doing it the other way bears a different price.
>
> Still, it does not change the amount of code that must be vetted during an audit, either way.
>

If you pick up 100% of the code that the post 1028 compiler lied about, then I agree. Unsafe is unsafe even if your compiler stays mum.

If you pick up less than 100%, I disagree.  In that situation the compiler will have "helped" you to reduce the amount of code to be audited.

And finally, were the 1028 extern!(D) default changed to @system, I disagree.  The amount of code in non-greenwashed @trusted wrappers should be smaller.  (note that I discount the one time audit of stable @system libraries)

On Tuesday, 26 May 2020 at 20:32:13 UTC, Paul Backus wrote:
> On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
>> Which will just lead people to pure @trusted: at the top of their code to get it to compile again, with or without extern(C) being @safe by default. Then someone that uses it as dependency will mistaken think it is @safe. What's to stop this kind of "greenwashing" and why is greenwashing only important to prevent when talking about extern(C) but every other code that will break from this change?
>
> The reason extern function declarations are particularly problematic is that changing them from @system-by-default to @safe-by-default can cause *silent* breakage in existing, correct code. By "silent", I mean that there is no message from the compiler warning you that the memory safety of the code has been compromised. It will still compile, and you will only find out that something has gone wrong when you run into memory corruption at run-time.
>
> This undermines the entire purpose of @safe, which is to automatically catch code with potential memory errors at compile time.

Exactly, that's what I think as well. What I'm trying to convey is that there's a lot of greenwashing that is going to happen. Code doesn't work, slapping @trusted everywhere til it works is what people are going to do, it doesn't matter if extern(C) is @safe or not. Greenwashing occurs no matter what. It's only natural with such a big breaking changing with a feature that you have to "trust".

Consider this:

Someone is writing code, it's @safe cause it is now the default (yay!). They come across unannotated code while searching for an answer. They copy paste it into their source, ops compile error! Can't use X in @safe code. Ok, so they annotate it as @system. Oh but now their @safe code can't call @system code. So what do they do? Annotate it as @trusted without checking it.

If Walter believed greenwashing was actually a problem, then the best solution to prevent it would be to not make @safe by default. If it's not that serious of a problem that he will push through @safe by default, then greenwashing isn't actually a problem and extern(C) should remain @system.

On Tuesday, 26 May 2020 at 22:47:03 UTC, Gregory wrote:
> If Walter believed greenwashing was actually a problem, then the best solution to prevent it would be to not make @safe by default. If it's not that serious of a problem that he will push through @safe by default, then greenwashing isn't actually a problem and extern(C) should remain @system.

I understand your point now, and I agree.

On 5/24/2020 6:04 PM, Timon Gehr wrote:
> Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing.

You and I are just going to disagree about that.