On 5/26/20 12:31 PM, 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?

If that's the case, it's the death of DIP 1028.

On 5/26/2020 9:31 AM, 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?

Nothing at all.

But I doubt there is much legacy non-compiling code around.

On 5/26/2020 1:32 PM, Paul Backus wrote:
> 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.

Can you post an example of currently compiling and correctly working code that will break?

Setting aside use of __traits(compiles, ...).

On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
> On 5/26/2020 9:31 AM, 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?
>
> Nothing at all.
>
> But I doubt there is much legacy non-compiling code around.

The intent of my above was to illustrate the difference between pre 1028 compiler behavior and post 1028 compiler behavior.  I'm not at all concerned with legacy non-compiling code of this nature.  I am concerned about the change in compiler behavior.

As you've confirmed, post 1028 the compiler will accept an @safe routine calling in to an un-annotated extern C function without complaint.

Andre, I hope this is clear enough for you.

On Wednesday, 27 May 2020 at 02:42:24 UTC, Walter Bright wrote:
> 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.

Unfortunately science and research Doesn't agree with you. https://en.m.wikipedia.org/wiki/Default_effect

On Wednesday, 27 May 2020 at 02:58:16 UTC, Andrei Alexandrescu wrote:
> On 5/26/20 12:31 PM, 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?
>
> If that's the case, it's the death of DIP 1028.

Walter has confirmed that this is indeed the case.  As you can read a few posts up his response to my "What am I missing?" query was "Nothing at all."

Yes, it's really that bad.

Your help in undoing this mistake would be greatly appreciated by me and by the authors of, literally, hundreds of posts in this thread opposing the DIP.

On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
> On 5/26/2020 9:31 AM, 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?
>
> Nothing at all.
>
> But I doubt there is much legacy non-compiling code around.

The point isn't that incorrect legacy code that didn't compile now does (although that does matter a bit), it's that newly written code will compile when it shouldn't.

Existing code will be full of extern(C) declarations that are implicitly and correctly @system now and will become @safe with dip1028, which means that when I write new @safe code calling those (could be through a deep dependency chain of inferred-@safety APIs, multiple dub packages...) I could easily find my new code compiling when it shouldn't.


Effectively, by silently @safe-ing things you can't infer, you will be changing APIs from @system to @trusted without any checks.


Just in case there's any confusion, here's a timeline:

1. library A is written containing a dangerous but useful extern(C) declaration assuming @system by default.
2. application B is written for and compiled with dip1028, @safe: at the top of every file.
3. B adds a dependency on A. It continues to compile as @safe, calling an unsafe C function.


This seems like one of those things where it's either wrong or a showstopper.

On 5/26/2020 11:20 PM, Bruce Carneal wrote:
> I'm not at all concerned with legacy non-compiling code of this nature.

Apparently you agree it is not an actual problem.

On 5/24/2020 3:40 AM, Stefan Koch wrote:
> The distinction is that you can find a slapped on trusted with a grep.

It's just as easy to use grep to *not* find @trusted.

On 5/27/20 1:49 AM, Walter Bright wrote:
> On 5/26/2020 9:31 AM, 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?
> 
> Nothing at all.

That means safe by default is effectively loosening D's notion of safety.

This DIP must go.