Help understanding no-runtime error?

[Manu]

On Thu, 14 Nov 2024 at 06:41, Walter Bright via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241114/33647e8c/attachment.htm>