I'm building a majorly stripped back environment, but not quite better-c. I removed druntime and building with an empty object.d, slowly filling it to understand the minimum set of things I need.

I have encountered a weird error though:

  enum x = "X" == "y";

  error : incompatible types for array comparison: `string` and `string`

Most things seem to use __cmp, and certainly "X".__cmp("Y") does compile
and work.
Does anyone know why this error message? What is the compiler doing
internally that leads to such an error message? Something's obviously
missing, but I don't know what...?

Likely:

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/equality.d

On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Likely:
>
>
> https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/equality.d
>

Oh that's so obvious! You know when the answer is right in front of your
nose, but you've convinced yourself it's somewhere else so you can't see it
no matter how long you stare at it! :P
Thanks fella! :)

On 13/11/2024 8:22 PM, Manu wrote:
> On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars- d@puremagic.com>> wrote:
> 
>     Likely:
> 
>     https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/
>     array/equality.d <https://github.com/dlang/dmd/blob/master/druntime/
>     src/core/internal/array/equality.d>
> 
> 
> Oh that's so obvious! You know when the answer is right in front of your nose, but you've convinced yourself it's somewhere else so you can't see it no matter how long you stare at it! :P
> Thanks fella! :)

This particular module has caused a lot of problems in -betterC.

It was fixed by turning on -allinst when -betterC is applied.

Hence this one is a well known internal detail :)

On Wed, 13 Nov 2024 at 17:41, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 13/11/2024 8:22 PM, Manu wrote:
> > On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars- d@puremagic.com>> wrote:
> >
> >     Likely:
> >
> >     https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/
> >     array/equality.d <https://github.com/dlang/dmd/blob/master/druntime/
> >     src/core/internal/array/equality.d>
> >
> >
> > Oh that's so obvious! You know when the answer is right in front of your
> > nose, but you've convinced yourself it's somewhere else so you can't see
> > it no matter how long you stare at it! :P
> > Thanks fella! :)
>
> This particular module has caused a lot of problems in -betterC.
>
> It was fixed by turning on -allinst when -betterC is applied.
>
> Hence this one is a well known internal detail :)
>


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.
A lot of it will resolve with move semantics and the proper emplace
expression that Walter's working... the rest of it, I dunno.
Like, look at `template _arrayOp(Args...)`, that's pretty wild stuff!

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.

> 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.

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.