On Thu, 14 Nov 2024 at 06:41, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 11/13/2024 12:01 AM, Manu wrote:
> I really wish there was an official document which maintained a list of all the
> expressions that generate runtime calls inside the compiler... there's a hell of
> a lot of them!
> If you sift through druntime, the fact that this code is such a mess is a really
> good indicator of some core language deficits. All these things handle SO MANY
> CASES.

The idea was to use the language itself to implement parts of the language, to
keep the compiler simple.

Whether this has succeeded or not is debatable.

I think it's successful in some domains. I like the idea of `_arrayOp` for instance, but the complexity of some of these implementations is kinda high.
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.
There is so much 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.
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.
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.

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.


> A lot of it will resolve with move semantics and the proper emplace expression
> that Walter's working... the rest of it, I dunno.

My progress on placement new has already yielded reductions in template bloat.

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.