core.traits?

[Mike Franklin]

On Tuesday, 8 January 2019 at 21:26:51 UTC, Steven Schveighoffer 
wrote:

>> I also feel the need for at least 1 another base library. My 
>> focus is on the fundamental compiler support functions, like 
>> initializing/comparing/copying arrays and general associative 
>> arrays support, as they are fundamental to the language and 
>> their compilers (not talking about TypeInfos, ModuleInfos, 
>> Object etc.).
>
> This is self-contradictory, as AA's require TypeInfo.
>
> Though I agree with the goal. It's just not a "now" goal, we 
> first need to fix these components so they DON'T depend on such 
> things as TypeInfo.

Steven is right (as usual) here.  There has to be a serious 
effort to remove the dependency on runtime information that is 
available at compile-time.  I tried quite hard on that in 
2017~2018, but I ran into all sorts of problems.

Exhibit A:
We can set an array's length in `@safe`, `nothrow`, `pure` code. 
But, it gets lowered to a runtime hook that is neither `@safe`, 
`nothrow`, nor `pure` 
(https://github.com/dlang/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1265).  In other words, the compiler-runtime interface is a lie.  So, if you try to rewrite that as a template to remove the dependency on `TypeInfo`, then the template will run through the semantic phase of the compiler and now you have to be honest, and it doesn't compiler. So, to make that work you have to make all of the code that `_d_arraysetlengthT` calls `@safe`, `nothrow`, nor `pure` to prevent breakage, you'll find that none of it compiles because the "turtles at the bottom" (i.e. `memcpy`, `malloc`, etc...) aren't `pure` or whatever attribute constraint you're trying to apply.

Exhibit B:
I tried to convert `_d_arraycast` to a template in 
https://github.com/dlang/druntime/pull/2268 and ran into similar 
problems.  Some tried to help with a `pureMalloc` implementation 
in https://github.com/dlang/druntime/pull/2276, but that didn't 
go well either.  Walter responded with "Since realloc() free's 
memory, it cannot ever be considered pure."  Well, what the hell 
are we supposed to do then? IMO, this having dynamic stack 
allocation for arrays and strings will help 
(https://issues.dlang.org/show_bug.cgi?id=18788).  GDC and LDC 
already provide this, but DMD's implementation is in druntime 
(https://github.com/dlang/druntime/blob/9a8edfb48e4842180c706ee26ebd8edb10be53f4/src/rt/alloca.d), so it requires linking in druntime, and now we're at a catch 22.  I asked Walter for help with this, as it is beyond my current skills, but he said he didn't have time.

Here's what I think will help:
1.  Get `alloca` or dynamic stack array allocation working.  This 
will help a lot because we won't have to reach for `malloc` and 
friends for simple allocations like generating dynamic assert 
messages
2.  Convert `memcpy`, `memset`, and `memcmp` to strongly-typed D 
templates so they can be used in the implementations when 
converting runtime hooks to templates.  I did some exploration on 
that and published my results at 
https://github.com/JinShil/memcpyD.  Unfortunately, DMD is 
missing an AVX512 implementation so I couldn't continue.

Lots of obstacles here and I don't see it happening without 
Walter and Andrei making it a priority.

Mike