A betterC modular standard library?

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 20 04:33:27 PST 2016


On Tuesday, 20 December 2016 at 09:56:34 UTC, Ilya Yaroshenko 
wrote:
>> Of course you can bundle your own Phobos.
>> If you put a std.* module in your path your build will be 
>> working against that instead. If you don't mess around with 
>> sc.ini it will override the default for that compilation.
>
> CPUID should be precompiled. So this does not work. If GLAS do 
> not need anything but CPUID, what the reason to depend on 
> DRuntime?
>
> Please stop to force me to use DRuntime because you think it is 
> better for Mir projects. This looks like DRuntime religion.
>
> A betterC library can be used with DRuntime. So I do not force 
> anyone to drop DRuntime. Please do not force me to use it.
>
> GLAS already works without DRuntime and I am happy about that.

What does "you can bundle your own phobos" have to do with that? 
No one's forcing you to do anything.

You're suggesting something radical*, other people are suggesting 
that maybe there are good compromises where everybody wins, 
avoiding fragmentation. Then you say that "looks like DRuntime 
religion" and claim you're being forced to modify your code to 
add extra dependencies. It doesn't make sense.

Your technical arguments have good content, in my opinion 
everyone would benefit from you writing them up with sufficient 
context for people who don't know what you know and without 
hyperbole (none of that "D will fail if we don't do X" or "phobos 
is bloated and useless" stuff, it doesn't help communicate your 
points). Developing the case study / thought experiment of 
getting two libraries (blas and fft) in to a traditional linux 
distro would be a great central point.

See https://github.com/dlang/DIPs/pull/51 where Andrei describes 
not only how he thinks things should be, but also explains in 
detail why other approaches won't work. Now consider that what 
you're talking about is a lot more important and 
different/disruptive than a new import syntax, so it deserves at 
least comparably good description.

* D used to have 2 standard libraries. That was not a happy time 
for the community. People are wary partly because of that.

P.S. a good example of the sort of statement that needs more 
explanation, at least for me:
> The betterC
> std.range and std.algorithm analogs would be released with new 
> ndslice
> implementation. Mir's algorithm would be faster then Phobos and 
> will
> generate less template bloat."
How? Why? Is ndslice actually capable of the same level of 
flexibility as std.algorithm and std.range? You're effectively 
saying "all that stuff that Andrei (and others) designed and 
wrote, I can do better" without really showing anyone why they 
should believe that.


More information about the Digitalmars-d mailing list