<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 24 Aug 2024 at 12:28, Walter Bright via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/21/2024 10:27 PM, Manu wrote:<br>
> That's not a C program, that's a D program with some C code sprinkled in.<br>
> But right... a mixture of extern(C) in D code, and also ImportC used in <br>
> conjunction, where the ImportC code makes explicit use of symbols that it <br>
> expects to find externally...<br>
> Feels unlikely, pretty contrived; why would you be using extern(C) if you are <br>
> also using ImportC? They're kinda mutually exclusive for my interest. I wouldn't <br>
> use ImportC if I was satisfied to write extern(C) bindings.<br>
<br>
I've used it in hybrid C and D programs. It also comes about when one is <br>
"transitioning" C code to D code. Enabling use of D code in a C project without <br>
needing a D main() entry point is a nice plus.<br>
<br>
<br>
> I mean, being overly cautious like this is not in the spirit of using C code at <br>
> all! C code will _always_ introduce these sorts of risks 100% without question. <br>
> If you're stressed about this, while also having no agency to control your <br>
> environment or test your programs validity, you kinda have no business linking <br>
> to C code in the first place.<br>
<br>
Some years back, I got into a terrific disagreement with everyone else in the D <br>
community when I wanted C declarations to default to @trusted :-/<br></blockquote><div><br></div><div>I might have been inclined to back you on that one... that said though, the real solution to that category of problem is to accept that we need annotated scopes.</div><div>We need to have:</div><div><br></div><div>@trusted {<br></div><div> some_code;</div><div>}
</div><div></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">I don't think people would feel particularly inconvenienced by C calls being unsafe if it's trivial to write an unsafe block.<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But all that as it is, so... we add a compiler flag to control whether these 2 <br>
> attributes are applied to ImportC declarations or not?<br>
<br>
I'm reluctant to add more flags as every one of them is a hack, and an admission <br>
of language design failure. A compiler should "just work".<br></blockquote><div><br></div><div>Look, ImportC is a gigantic effort, and it's safe to say that with this limitation, it is a critical design failure!</div><div>I literally can't use it at all. The most useful case for ImportC I've ever encountered is precisely the case that's explicitly prohibited by ImportC... if that's not a design failure, what is?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The current situation is not reasonable. You've done all this work and made all <br>
> this hype, the first time I want to make use of it, it turns out it's not <br>
> actually usable by the exact sort of code that seems the most likely to want to <br>
> use the feature in the first place!<br>
> C doesn't throw<br>
<br>
Yes, it does. setjmp()/longjmp() are in the C Standard 7.13.<br></blockquote><div><br></div><div>That's way outside the language. nothrow has nothing to say about this.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> or GC, period.<br>
<br>
> Of course I can contort a C environment to do <br>
> whatever I want; but the argument that C can throw or can GC alloc implies that <br>
> the C code is not actually C code... it is infact actually just a small piece of <br>
> connective tissue in some non-C project.<br>
> A C library that is a self-contained package does not call C++ code or D code. <br>
> We need a way to assert this case. I think a compile option which asserts this <br>
> case seems fine.<br>
> Maybe apply the arg to a directory; in the event there are multiple C libraries <br>
> being included in the project, it only applies to C code under that path, like <br>
> some self-contained libraries?<br>
<br>
I understand your concern. Perhaps we can approach it from a different direction <br>
- why do you need the code to be nothrow and @nogc?<br></blockquote><div><br></div><div>That's just what I'm into. You just can't have a GC when you have only 200K of ram in total. I will not link the GC.</div><div>Similarly, exceptions are just worthless noise. They don't make the language better, and I'm trying to tighten what I can control.</div><div>Exceptions aren't the same in terms of being ultra-limiting though, you can still make use of a lib in some leaf function; just as long as you catch before returning to the main ecosystem, which I'm quite happy to strictly enforce.</div><div><br></div><div>You shouldn't have created nothrow and <a class="gmail_plusreply" id="plusReplyChip-3">@nogc</a> if you didn't intend for me to use them...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't know if this would work for you, but you could also try -betterC, which <br>
is implicitly @nogc.<br></blockquote><div><br></div><div>Yeah, it's a tricky migration. with nothrow and @nogc I'm finding I can make progress incrementally, but not the case with BetterC.</div><div>Also, there's things that you lose with BetterC that I don't object to. I like classinfo, and I like dynamic casts, and several other things I noticed when I tried it out that I can't remember right now.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For reference, the following enables calling a throwing function from a nothrow <br>
function:<br>
<br>
```<br>
nothrow int horse(int x, int y)<br>
{<br>
try<br>
{<br>
battery();<br>
}<br>
catch (Exception e)<br>
{<br>
}<br>
return x = y + 3;<br>
}<br>
<br>
int battery()<br>
{<br>
throw new Exception("hello");<br>
}<br>
```</blockquote><div><br></div><div>Yes, I mentioned that above... but I'm not going to do that at every call to the CRT or the OS. I know perfectly well that malloc() won't throw.</div><div>I'm trying to systematically minimise waste.<br></div></div></div>