On Tuesday, 26 May 2020 at 13:21:08 UTC, Johannes Loher wrote:
> Am 26.05.20 um 15:10 schrieb Panke:
>> 
>> The bazel community has lots of such switches. Basically every new behaviour get's introduced with a --preview switch, that will turn into a --revert after some time.
>> 
>> For each switch there is a github issue, explaining the change it detail. Why it was necessary, what the changed behaviour is, how to migrate and the timeline for this particular switch.
>
> D has the same thing (e.g. -preview=safedefault will enable this DIP). The main difference to Johannes T's suggestion is that these preview and revert switches are only a temporary measure to ease the transition. They do not create different versions of the language permanently.

What we don't have is good documentation and a clear timeline for the switches.

On Tuesday, 26 May 2020 at 12:51:59 UTC, Atila Neves wrote:
> On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
>> On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote:
>>> [...]
>>
>> If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true.
>
> -preview=safe now
> -revert=safe "tomorrow"

Does that separate "safe by default" from "c functions are assumed safe"?

On Tuesday, 26 May 2020 at 12:51:59 UTC, Atila Neves wrote:
> On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
>> On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote:
>>> [...]
>>
>> If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true.
>
> -preview=safe now
> -revert=safe "tomorrow"

If these are permanent, an ugly fork will have occurred in all but name.

If these are temporary, we'll have gained little since the damage caused by assuming human checked routines are @safe will remain after the switches are removed.

I think there is an exit to the current impasse that has been overlooked thus far.

The key question is, during a safety audit, how to find the unsafe sections of code that need to be vetted thoroughly. If DIP 1028 is kept as is, these sections can be found by `grep @trusted|extern\(C`. If DIP 1028 would be amended as many argue for, it would be `grep @trusted`. But isn't grep a rather crude tool, and wouldn't the compiler be able to create more useful reports either way?

The compiler already has options for listing gc allocations (-vgc) and variables that go into thread local storage (-vtls). A new option could be implemented to list all @trusted functions and all calls into extern(C[++]) functions from within safe sections.

It is the calls into extern(C[++]) functions that cannot be guaranteed to be safe, irrespective of whether the declarations are marked @trusted or @safe. So listing these calls is much more valuable than grepping for @trusted, which can be misused as "@trusted extern(...". If a C library has a proper D wrapper that defines a safe interface, only the @trusted functions in the wrapper would appear in the list, not the extern(C) calls that are made within its @trusted functions. The list could possibly be reduced by excluding functions that are never called, making it even more valuable.

@trusted is not a seal of approval. It bears no signature, nor a hash of the implementation. It is simply a bridge from safe territory into unsafe territory, and is a checkpoint that cannot be skipped in any certification process.

Considering this, the compiler can actually produce a hash of the implementation of trusted functions as part of this list. A certification authority can then actually use this list to maintain a table of sections, hashes and stamps. If a new release needs to renew its certification, the earlier table can be compared against the current list, and functions whose hash didn't change need not be reviewed again. Extrapolating even further, this could be the basis of a repository of approvals from various individuals and authorities representing statements like "I have looked at this function carefully and I believe it can indeed be trusted".

I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe.

-- Bastiaan.

On 5/25/20 5:17 AM, Walter Bright wrote:
> On 5/23/2020 5:13 AM, Steven Schveighoffer wrote:
>> And let's be honest here, if you are OK with it, putting @trusted: at the top of your extern(C) functions is fine with me. At least that's not a lie.
> 
> @trusted says the interface to the function is safe. If the programmer did not actually check the interface, it is greenwashing. For example, memcpy() does not have a safe interface and marking it @trusted doesn't improve matters.

Yes, and the programmer did this on purpose. To quote someone else `My reasoning at the time was "I trust libclang".` In that sense, it's not a lie, or "incorrect," you are just trusting that whomever wrote that C library (maybe it was the author of the prototype) followed strictly the D safety rules. It's possible to write a function that takes 2 pointers and a size_t that is @safe, just like memcpy (it won't do anything, but there is nothing inherently wrong with that). If it were possible to determine directly from the types of parameters that a function wasn't safe, we would not be having this discussion.

So "trusting" a library regardless of interface is what @trusted: does. And while I wouldn't do that, or use a library that does that, at least I can see where the problem is! @trusted code is hard to write correctly, and there's going to be greenwashing abound when this change comes about. I can even envision someone *recommending* "Don't import core.stdc.x, just declare the prototype yourself, and you can then call them from safe functions!".

Greenwashing by the compiler essentially adding @trusted to every C porototype doesn't make it any better. I'd much rather have a clear indication that someone made this conscious decision, correct or not, and here is where you should look to find the problems. If I am interested in ENSURING that all code I use is @safe or correctly @trusted, then I know how to find those points of contention if the @trusted attribute is required where it should be.

The biggest problem with the magic greenwashing of this DIP is that there is 10-20 years of existing D code with extern(C) function prototypes that are specifically unmarked BECAUSE the author knew that meant @system. I don't know how this DIP can be approved just on that problem alone.

I hope something better comes out of this discussion, I'm going to mute it now because I don't have the time to keep arguing against people who don't seem to understand either memory safety or human nature.

-Steve

On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
> [snipped an outline of tooling to mitigate 1028 damage]
>
> I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe.
>

Yes.  Tooling is good and will be much appreciated if 1028 stands.  Reducing the need for tooling is even better.

@safe: the compiler checks
@safe post 1028: the compiler checks, sometimes, just not in the scary parts

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:
>> [snipped an outline of tooling to mitigate 1028 damage]
>>
>> I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe.
>>
>
> Yes.  Tooling is good and will be much appreciated if 1028 stands.  Reducing the need for tooling is even better.
>
> @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.

> @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.

-- Bastiaan.

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.

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.

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:
>>> [...]
>>
>> Completely agree but my above says nothing about @trusted.
>>
>>> [...]
>>
>> 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.

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?