A betterC modular standard library?

[Andrei Alexandrescu via Digitalmars-d]

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?

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



Andrei