A betterC modular standard library?

[Ilya Yaroshenko via Digitalmars-d]

On Sunday, 18 December 2016 at 20:16:11 UTC, Andrei Alexandrescu 
wrote:
> On 12/18/2016 03:10 PM, Ilya Yaroshenko wrote:
>> On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
>>>> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright 
>>>> wrote:
>>>>> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>>>>>> We already have better `cpuid` and better `random` 
>>>>>> packages.
>>>>>
>>>>> Great! Please PR them for Phobos.
>>>>
>>>> cpuid is used in Mir GLAS and it should be a betterC library.
>>>
>>> It's this kind of imaginary dialog that I don't quite grok:
>>>
>>> Ilya Yaroshenko: "I can't use druntime's cpuid so I defined 
>>> my own."
>>> [...]
>>> IY: "..."
>>>
>>> It's this kind of stuff I need to have a better understanding 
>>> of. Some
>>> technical arguments are meaningful, some others point to 
>>> problems with
>>> obvious solutions that are somehow shunned, and yet others 
>>> are like a
>>> hidden Markov model - I see the effects, but I don't see the 
>>> causes.
>>>
>>>
>>> Andrei
>>
>>
>> My last argument was:
>> ----
>> Linking compatibility. Assume A has builded a betterC library 
>> AA using
>> GDC version XXX and B has builded a betterC library BB using 
>> LDC version
>> YYY.
>>
>> Question: how mister C can use BB and AA together in his 
>> C-library if
>> both this libraries depends on different DRuntimes (compiler 
>> and version)?
>> ----
>
> My understanding is that if cpuid_v2.d does not pull any 
> dependency, it doesn't matter whether it sits in druntime or 
> elsewhere. Is that the case?
>
>> DRuntime is large and evaluates fast.
>
> So is it moving too slow or too fast?

It is too slow as library to contribute to and too fast as 
standard library to depend on.

>> We have not backward binary
>> compatibility in DRuntime and we have not binary compatibility 
>> between
>> different compiler versions.
>
> Even if we don't, we can guarantee that core.cpuid_v2 adds no 
> link-time dependency. We may offer it as a pure template 
> library, or as C APIs. Whatever floats your boat. Is this 
> enough for ensuring compatibility?

I need to understand how it is can be done because I did not find 
a valid solution.

mir-cpuid has global symbols, they are accessed using extern(C) 
API. If multiple libraries trying to initialize it than it will 
be initialized only once.

extern C API does not solve a problem with DRuntime because 
current DRuntime is not a betterC library and it is huge. A huge 
betterC library is a problem too because it is less portable.

Anyway, if you find a proper solution please share it. How it can 
be implemented as template library? Does different libraries will 
have their own cpuid instantiations and __gshared symbols?

How modularity can break existing Phobos? Why not to allow new 
packages like mir-cpuid and std.allocator to be a betterC library 
with their own repository? This will not break existing Phobos 
and Druntime but this will allow me to write server and numeric 
software without copy-pasting Phobos codes. I prefer to fork 
something rather then copypast.

My plans to work on:
1. Low-level numeric libraries
2. Low-level fast async I/O adaptive generic event loop, 
asymmetric green threads, http2
3. Microelectromechanical systems

They will require new threads, new timers, new mutexes, new event 
loop (existing C libs are slow), to be used.

Existing one does not satisfy my requirements.

I do not earn any money for this work.

I am working on this projects because I believe in D and believe 
that my current and future clients will believe in D much more 
then now. I know what they need.

Ilya