A betterC modular standard library?

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 18 09:41:31 PST 2016


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.


> 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. Then lightweight threads, multithread GLAS, matrix
> inversion. Fastest I/O and http2 ...
>
> (they all are betterC modular libraries)

Propose them for Phobos!


> Andrei and probably 90% of existing D users don't want Phobos to move this
> direction.

I don't understand that point. What direction?


> In other hand I need a commercial attractive D infrastructure for large and
> heavy system projects. There is no commercial perspective for me to contribute
> to Phobos because:
>
> 1. Phobos version depends on compiler version. Delay with LDC release is too
> large. It should / can be one day.

The language evolves over time, and the standard library must, too. It happens 
with every language.


> 2. We can not do hot fixes in Phobos without compiling and deploying patched
> libphobos. Mir's DUB package are much more flexible.
>
> 3. Dependencies should be clear. Modularity is a proper way for large std
> library. In phobos everything integrated with everything. DRuntime -> Phobos
> abstraction is weird for betterC because system modules can depends universal
> algorithms, but universal algorithm are more portable if they have not system
> dependencies.

Not sure what you mean. Algorithms in Phobos are not dependent on system 
idiosyncracies.


> 4. Phobos does not provide and will not provide betterC guaranties. If something
> works for betterC mode now it may not work in the future release.

I've done a fair amount of work to remove such things. Clearly more can and 
should be done.

Generally, we do have a goal of making Phobos entirely "pay as you go" instead 
of being so interconnected (which is what betterC is really all about). We can 
definitely use help in improving that and helping it along.


More information about the Digitalmars-d mailing list