ImportC and nothrow/@nogc?

[Paolo Invernizzi]

On Tuesday, 27 August 2024 at 06:32:06 UTC, Manu wrote:
> On Tue, 27 Aug 2024 at 04:17, Timon Gehr via Digitalmars-d < 
> digitalmars-d at puremagic.com> wrote:
>
>> On 8/26/24 07:37, Walter Bright wrote:
>> > On 8/24/2024 10:15 AM, Manu wrote:
>> >> *sigh* ... I'm not going to do that.
>> >> ImportC either works, or it doesn't... and it currently 
>> >> doesn't work,
>> >> and I'm just going to move on.
>> >> By far the easiest and least ridiculous feeling thing can 
>> >> do right now
>> >> is to just prototype the occasional C library call inline 
>> >> immediately
>> >> before the call, which is what I've moved on with.
>> >> Fortunately my call volume is low.
>> >
>> > You're right, that will work.
>> >
>> > I tried to make C calls default to @trusted. Every single 
>> > person in the community who voiced an opinion on it was dead 
>> > set against it. But here you are, saying who cares what C 
>> > does.
>> >
>> > I've got a cannon on one side aimed at me, and a flak gun on 
>> > the other side.
>> >
>> > What do you suggest I do?
>> >
>>
>> Marking every C function `@trusted` would not solve his 
>> problem. What would solve his problem is if ImportC supported 
>> C extensions that let you mark groups of declarations using D 
>> attributes. Then you can put those in the C files that you 
>> import.
>>
>
> I could live with that... though I don't necessarily agree.
> I stand with Walter in principle on this; C prototypes should 
> just be @trusted.

Again, a big NO

> If you import and link a C library; you are 'trusting' it by 
> definition.

Again, a big NO

> You're making use of some middleware, and you're not in control
> of the code... it is as it is, and you decided to use it anyway.

@trusted relates to _memory safety_, nothing more, it's not about 
the distinction between crap codebases and excellent codebases.

You are in control of reading the documentation of the external C 
function
You are in control of understanding that some C function is NOT 
memory safe.
You are in control that you CAN'T call the function from @safe 
code without sanitising its input with some other @trusted D 
function.

You still mix memory safety with other completely different 
things.

> You either trust it (and link it into your software), or you 
> don't.

That's nonsense, again, see above

> Nobody gains anything from causing a hassle every time you want 
>  to call
> into a library that you've opted in to. The *whole point* is to 
> use the
> library; what possible advantage could there be to making that 
> a pain in the arse?

Best effort towards memory safety.
If you don't care and are searching for no hassles just don't use 
safe at all in your codebase

> Can we direct this thread back towards nothrow and @nogc? This 
> wasn't actually a conversation about @trusted...

It seems to me actually that there's still a lot of confusion 
about @safe / @trusted / @system from time to time, as your 
thread is showing.

So I think this digression is just prophylaxis against the 
@trusted virus

  :-P