ImportC and nothrow/@nogc?
Manu
turkeyman at gmail.com
Sun Aug 25 05:12:42 UTC 2024
On Sun, 25 Aug 2024 at 13:21, Timon Gehr via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:
> On 8/25/24 04:04, Manu wrote:
> > On Sun, 25 Aug 2024 at 10:56, Timon Gehr via Digitalmars-d <digitalmars-
> > d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> >
> > On 8/24/24 19:10, Manu wrote:
> > >
> > > Some years back, I got into a terrific disagreement with
> everyone
> > > else in the D
> > > community when I wanted C declarations to default to @trusted
> :-/
> > >
> > >
> > > I might have been inclined to back you on that one...
> >
> > Well, you'd have been wrong. Just remove @safe at that point.
> >
> >
> > Well I think the proper solution is to allow the user to declare unsafe
> > (ie, @trusted) code blocks, and make unsafe calls from within those
> > blocks, which would include calls to C code.
>
> `@trusted` does not mean unsafe. `@trusted` means memory safe but not
> automatically checked. Some `extern(C)` functions can be marked
> `@trusted`, it's just a really bad default as memory-unsafe interfaces
> abound in C.
>
> Anyway, I fully agree there would be more ergonomic ways to design those
> features.
>
Yeah the 'trusted' terminology doesn't actually map well to the operation
that the programmer usually wants to perform, which is "I am about to do
something unsafe, but I'm trying to assert confidence that I knew what I
was doing".
An 'unsafe' scope is almost always what the user wants. @trusted sits
awkwardly conceptually; I see provably-safe and unsafe, and that's it. Any
middling is a programmers effort to make use of unsafe machinery and assert
that they thought they did it right; while leaving a trail that you can
search for in the code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240825/06c4f2b4/attachment-0001.htm>
More information about the Digitalmars-d
mailing list