core.traits?
Mike Franklin
slavo5150 at yahoo.com
Wed Jan 9 02:32:50 UTC 2019
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
More information about the Digitalmars-d
mailing list