A betterC modular standard library?

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 18 11:28:24 PST 2016


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

Andrei Alexandrescu: "OK, so what's different?"

IY: "Mine has a few engineering improvements."

AA: "Cool, why don't you merge them into core.cpuid?"

IY: "Well mine doesn't have a shared static constructor, so it doesn't 
need a runtime to automatically call that library initialization 
function. User need to explicitly call an init function before using it."

AA: "I understand. Great, so how about this - we add your code to 
core.cpuid_v2 to druntime. Then we make all in core.cpuid to forward to 
it so there's no duplication. It all works out!"

IY: "No, I don't want to do that. It's still in druntime and I don't 
want druntime. I want betterC."

AA: "But it will be compilable with betterC and we can add unittests to 
make that happen. YOU HAVE MY SUPPORT. Let's do it."

IY: "No, I want to change it often. The deployment schedule of druntime 
is too slow."

AA: "How often do you need to change it? Is it that unstable?"

IY: "Um, not too often."

AA: "Then what is the matter? Are you worried about the IP of the 
engineering improvements you are making? Are you licensing this 
differently?"

IY: "No, it's for the most part similar to core.cpuid and the license 
will be also Boost."

AA: "Then what is the matter? Do you want me to wait until you release a 
stable mir.cpuid and copy it over with credit, per the Boost license, to 
core.cpuid_v2?"

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



More information about the Digitalmars-d mailing list