<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Nov 2024 at 06:41, Walter Bright via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">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 11/13/2024 12:01 AM, Manu wrote:<br>
> I really wish there was an official document which maintained a list of all the <br>
> expressions that generate runtime calls inside the compiler... there's a hell of <br>
> a lot of them!<br>
> If you sift through druntime, the fact that this code is such a mess is a really <br>
> good indicator of some core language deficits. All these things handle SO MANY <br>
> CASES.<br>
<br>
The idea was to use the language itself to implement parts of the language, to <br>
keep the compiler simple.<br>
<br>
Whether this has succeeded or not is debatable.<br></blockquote><br></div><div class="gmail_quote">I think it's successful in some domains. I like the <i>idea </i>of `_arrayOp` for instance, but the complexity of some of these implementations is kinda high.</div><div class="gmail_quote">The biggest black stain that I see is core.lifetime... these are just far too low-level and important/critical pieces of infrastructure to leave up to such unbelievably awkward implementations; the core issue is that these are deep-set and fundamental language semantics, and trying to implement them in-language is pretty absurd, because they're building-blocks themselves.</div><div class="gmail_quote">There is <i>so much </i>code in there, and it's so ugly and gross. It all depends on the optimiser to be reasonable; without inlining it's a disaster. It's like cancer to symbolic debugging (which people still seem to dismiss like it's not essential for professional-grade productivity); steeping though core.lifetime in debug builds is frankly embarrassing.</div><div class="gmail_quote">Like; you get to a new statement, or an emplace or something and you obviously want to step inside the constructor to watch it construct... or even just a `move` or `forward`; those in particular appear in argument lists all the time to setup args for a call... you try and step-in to a function you want to inspect, and you have to work your way through 50 lines of `move` or `forward`, stepping in and out of stupid auxiliary nonsense before you step into the function that you actually want to inspect.</div><div class="gmail_quote">Those 2 things in particular need to be intrinsics (as they are moving towards with the move semantic work); they shouldn't themselves yield a single line of execution! There's no business for there to be a physical `move` or `forward` function to step-in to; it should just be an intrinsic that coerces an argument into the proper form... there's no code to execute.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Anyway, we seem to be moving in a good direction in this stuff. I hope you saw my emails where I took this stuff for a test drive.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> A lot of it will resolve with move semantics and the proper emplace expression <br>
> that Walter's working... the rest of it, I dunno.<br>
<br>
My progress on placement new has already yielded reductions in template bloat.<br></blockquote><div><br></div><div>As it should! That's a large part of the point... although a uniform syntax and concentrating initialisation code in one semantic location are pretty worthy goals.<br></div></div></div>
</div>