On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> Consider the common (because that's how D started out) case of:
>
> ----- clibrary.d --------
>
>     T massage_data(... many parameters ...);
>     ... 200 more such declarations ...
>
> ----- app.d ----------
>
>     import clibrary;
>
>     void useClibrary( ... parameters ...) {
>         massage_data(parameters);
>     }
>
> ---------------------
>
> This code, today, does not use annotations and it works. It's been working
> for a long time. Now, we implement the amendment, and it stops compiling
> because useClibrary is @safe and massage_data is @system. The user is faced
> with the following alternatives:

Why are you assuming that the only thing wrong with useClibrary() is that it would use a C declaration that is @system? All @system code I've written is @system and wouldn't compile to @safe even if extern(C) declarations are wrongly annotated as @safe.

What if app uses core.stdc? All those functions have already been annotated as @system. Any code that uses the C stdlib is going to break right now anyways.

What's stopping someone from just as easily slapping @trusted: at the top of app.d? Since there are going to be more issues than simply calling extern(C) functions.

I find it odd also that you are using one of the rationales against making @safe the default (that code will break and lazy solutions will be employed to make them work again), as a means to make @safe, less memory safe.

On Friday, 22 May 2020 at 17:54:26 UTC, Atila Neves wrote:
> On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer

>> And so, you are free to pepper your @safe code with dangling pointers. Sure, you can claim that the C++ library didn't "corrupt your code", which is the case for ALL libraries if you use them properly. You did it, you created a dangling pointer, not the library.
>
> Right. And the point I was trying to make wasn't "look at what I did, it's cool". No, what I did was dumb. So dumb it took you no time at all to point out one of my mistakes. My point is that the result of making declarations implicity @system instead of @safe would make people just slap @safe on them without really thinking about it to get their code to compile. Like I did.

So force people to slap @trusted instead, via compiler complains, not @safe, and reviewers will catch the laziness: why this is worst that what you picture?

On Friday, 22 May 2020 at 18:34:32 UTC, Gregory wrote:
> [snip]
>
> Why are you assuming that the only thing wrong with useClibrary() is that it would use a C declaration that is @system? All @system code I've written is @system and wouldn't compile to @safe even if extern(C) declarations are wrongly annotated as @safe.
>
> What if app uses core.stdc? All those functions have already been annotated as @system. Any code that uses the C stdlib is going to break right now anyways.
>
> [snip]

The breakage would produce error messages. Annoying to fix, but at least obvious. The worry is more about not receiving any error messages. In other words, some code would compile as @system previously, but now would compile as @safe with nothing else changing. It's @safe, but is it really safe?

On 5/22/20 1:52 PM, jmh530 wrote:
> On Friday, 22 May 2020 at 16:47:34 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> You can't, you don't control that code, someone else does (this is important, you can declare extern(C) functions anywhere, even locally).
> 
> You can make a separate module with one function that just calls the `free` function and has the @system attribute. Then, just change the import for the free function to that new module. Annoying, but potentially fix-able.

You are using library fubar.

fubar defines a function foo:

void foo(int *p)
{
   import fubar.cfunctions : free;
   free(p);
}

After this DIP, it now becomes completely assumed @safe. The author of fubar intended it to be @system. But now all safe code can now call it, and there's nothing you can do except ask them to fix both modules to be @system. You can just stop using the library, sure. But you have no control over whether fubar's code is properly written. That is the point.

If the C prototype was instead considered @system, then foo stops compiling (for good reason), and you can either motivate the author to fix it, or use a different library. But at least you can't ACCIDENTALLY use it in @safe code.

Essentially all code written before this DIP is switched on is completely suspect, and needs manual verification -- if you care about safety at all.

-Steve

On Friday, 22 May 2020 at 18:44:09 UTC, Steven Schveighoffer wrote:
> [snip]
> You are using library fubar.
>
> fubar defines a function foo:
>

I agree with most of what you said.

I was trying to make the point that this is a contrived example where we know for sure that one function should be @system and is actually @safe. For one function where you know it should be @system, then you can create a fix. However, it's unreasonable to require that for all of the code from outside modules without attributes (even if it could be possible to write something in D that makes it relatively less painful to do this).

On Friday, 22 May 2020 at 18:32:59 UTC, Steven Schveighoffer wrote:
> So the solution is -- make the compiler be dumb for you? If you are going to incorrectly put @safe on it, I want you to have to do it because YOU made a conscious decision to be careless, not have it done for you because you forgot.

Yea, agreed.  If a library works around an extern(C) API by slapping `@safe:` on it, this is a visibly problematic thing to do, and people can file bug reports and patches about it.  And we can have well documented warnings about this being a bad way to do things.

If a library just gets extern(C) APIs as @safe by default, then it's not visibly obvious that this is problematic.

I would much rather have the problematic thing as something visibly done by the developer, than automatically done by the compiler.

On 22.05.20 20:24, Atila Neves wrote:
> On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
>> So the DIP itself wasn't good enough to convince you.
> 
> Had that been the case, I would have rejected it.

You said the DIP as written felt "icky". And only after a chat with Walter did that feeling go away. You're saying you would have accepted a DIP that feels icky? DIPs are supposed to be convincing, not barely tolerable.

> memcpy isn't a good example since it's explicitly @system:
> 
> https://dlang.org/phobos/core_stdc_string.html#.memcpy

core.stdc.string.memcpy is a specific binding to C's memcpy. Any other declaration of it will be implicitly @safe.

"But why would anyone declare `memcpy` themselves, when they can just import the one from `core`?" I hear you ask. And I answer:

1) Shouldn't matter, if we're talking about a principled safety system. But I realize that the leadership isn't interested in that anymore.

2) I have quickly typed out C declarations before, because it was more convenient than looking up where it is exactly in the standard library. And we're all about catering to convenience now, aren't we?

> Yes. But most of them aren't like memcpy. Most D code calls other D code, not C.

Most D code isn't behind an `extern (C)` prototype. Virtually no one is (strongly) against making D functions @safe by default.

> Am I saying nothing bad can happen if we implicitly trust extern(C) declarations? No. I'm saying we'll be no worse off if they're all implicitly @system.

"No worse off" should not be good enough for a DIP.

> This compiles with no warnings right *now*:
> 
> void main() {
>      import core.stdc.stdlib: free;
>      free(cast(void*) 42);
>      free(new int);
>      free(&main);
> }

And this doesn't compile right now, but it will with DIP 1028:

----
extern (C) void free(void*);
void main() @safe {
     free(cast(void*) 42);
     free(new int);
     free(&main);
}
----

Yes, yes, I know. That's soo much less common in the real world. But before the great @safe schism that is happening right now, @safe wasn't about catching more bugs than not on average. It was about being "100% mechanically checkable" (Walter's words).

I for one liked it better when it had that aspiration. And I was contributing towards that goal (latest PR was merged just yesterday, coincidentally [1]). I have no interest in a version of @safe that is deliberately fuzzy, where I have to defend safety fixes against convenience arguments.


[1] https://github.com/dlang/dlang.org/pull/2773

On Friday, 22 May 2020 at 19:16:26 UTC, ag0aep6g wrote:
> I for one liked it better when it had that aspiration. And I was contributing towards that goal (latest PR was merged just yesterday, coincidentally [1]).
>
> [1] https://github.com/dlang/dlang.org/pull/2773

Thank you for that PR, by the way. The new version of the spec is *much* clearer, and actually helped me find a subtle safety issue in my own code that I'd previously overlooked. I sincerely hope the D leadership appreciates how valuable this kind of work is.

On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
>
> Sorry, I didn't express myself well. I meant that the user can still mark functions as @system, they just have to do it explicitly.

Hm, DPP might be of help here. Becuse I quess you are going to make sure it'll mark everything `@system`?

On Friday, 22 May 2020 at 12:25:23 UTC, jmh530 wrote:
> On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
>> [snip]
>
> Thank you for your reply.
>
> How about some time before this DIP is fully in the language, a compiler flag is added that will produce warnings for when extern prototypes without explicit @safe/@trusted/@system are used? Or something like that. I have a good sense of when my own code uses extern(C), but not always other people's.

There is no reason to make the compiler do that. I think it would be more appropriate for D-scanner to do that or more practically for dub

https://github.com/dlang-community/D-Scanner