On Wed, 28 Aug 2024 at 23:52, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 29/08/2024 1:41 AM, Manu wrote:
> >      > And if someone does a binary-back-door... who cares? That's
> >     called a BUG.
> >      > They're playing with fire already! C doesn't have any such type
> >     safety, and they
> >      > shouldn't expect it to.
> >      > They know what they did; they did it intentionally, surely knew
> >     what the risk
> >      > factors were, and they are naturally expected to not write such
> >     bugs into their
> >      > program.
> >
> >     The author of the C code likely has no idea that the caller from D
> >     exists let
> >     alone that it would require that the C code not call any D functions.
> >
> >
> > The author of the library expects you to use the library via the API
> > they provide... their API is C code; if C code is nothrow @nogc, then
> > the callback you provide is necessarily nothrow and @nogc also.
> > I really can't see the fuss here...
>
> I've just had a thought, an old idea of mine is called contract invalidation. What it does is if you have an argument for say a function pointer that doesn't have an attribute, the attribute comes off the called function.
>
> Useful for opApply, but it might be perfect here too.
>
> ImportC can default to nothrow, @nogc, @system.
>
> If you pass in a callback that throws or uses GC, then so does the function.
>
> Its @system, so compiler isn't making any guarantees in terms of safety anyway.
>
> I know Timon wants something more powerful than this, but... it could work here.
>

That's an interesting idea in other contexts; but I don't see it's relevant here. This is not an engineering problem that needs to be solved.

On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
> I just tried using ImportC for the first time ever, but I was surprised
> when I immediately received a sea of errors calling the C symbols from
> `nothrow @nogc` functions.
> My entire program is `nothrow @nogc`... I assumed ImportC would be
> supremely suitable in this context, but apparently not...
>
> Is there something I've missed? Is there a plan for this?
> I found just one single very short forum thread...
>
> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<

I missed most of this somehow, but after reading the posts in this thread, here's what I think:

* Automatically making declarations obtained via ImportC default to `@trusted` is a terrible idea.
* Making declarations obtained via ImportC uncallable from D code annotated with `@trusted nothrow` with no escape hatch is also a terrible idea.

This should work:

@trusted {
    import mycfile;
}

Or, at least, *something* like this should work. I don't think it's acceptable to ask people to have to translate (by hand or otherwise) C code to be able to add attributes to it. Whatever attributes my D code has or not, I should be able to call C code via ImportC if I'm convinced the C code is compatible. *Especially* for `@nogc nothrow`. Could a "C" function throw? Yes. Is that going to be common? No. The same goes for allocating with the GC or not.

On 8/29/24 18:01, Atila Neves wrote:
> * Making declarations obtained via ImportC uncallable from D code annotated with `@trusted nothrow` with no escape hatch is also a terrible idea.

https://forum.dlang.org/post/v0urjh$58i$1@digitalmars.com

On 8/28/24 00:04, Walter Bright wrote:
> On 8/26/2024 11:12 AM, Timon Gehr wrote:
>> 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.
> 
> People are very reluctant to modify their C files, as they usually come from outside their organization. I've done a lot of work on ImportC to get it to work with unmodified C code.
> 
> Note that Manu rejected my suggestion to use ImportC to generate .di files of the function prototypes, and then edit in the attributes. This is equivalent to your suggestion.

No, this is completely different to my suggestion.

On Thursday, August 29, 2024 1:50:10 PM MDT Steven Schveighoffer via Digitalmars-d wrote:
> On Thursday, 29 August 2024 at 19:32:06 UTC, Stefan Koch wrote:
> > That requires modification of the C header.
> > maybe using the attribute on the import is a better idea.
> > Perhaps it is reasonable to have both, but I can imagine people
> > not wanting to change their headers.
>
> You can't import headers with importC. You have to import C files.

I was _really_ confused when I found that out, and I have no clue why it was done that way, since you don't normally #include .c files.

> It is already necessary to create shim C files.
>
> So in the shim, you set the attributes, and import the headers you need.

I do think that it's kind of dumb that you can't just import C headers with importC, since it seems like that would be the obvious thing that you're trying to do, but putting something in a shim file to affect the attributes isn't terrible when you already have to have one.

- Jonathan M Davis