A betterC modular standard library?

[Dicebot via Digitalmars-d]

On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:
> Hi,
> 
> Who is interested in betterC _modular_* standard library?
> I am planing to make libmir org a community for it.
> Thought and concerns?

I also consider Phobos a lost cause only suitable for scripting
purposes. However what you try to do won't be acceptable for me either
(see below).

> We already have better `cpuid` and better `random` packages. 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 ...

I consider only algorithms and interfaces suitable for standard library.
GLAS, I/O, HTTP - this is exactly all the stuff I want to see removed
into separate dub packages and maintained as such.

> (they all are betterC modular libraries)

.. and this "betterC" weirdness you use with your own meaning is
definitely something I don't want to _ever_ see as standard library
approach. It is similar to `malloc` vs `GC` debate for Phobos, because
correct answer tends to be "neither", with rationale that any library
utility that has to care about the difference is hardly generic enough
for unconditional distribution.

------------------------

My own dream path for fixing Phobos may look like this:

1) Start with separating environment-agnostic core (algorithms and
API's) from utilities
2) Rewrite all higher level utilities in a way that they don't have any
inter-dependencies and only allowed to use algorithm/API modules
3) Move higher level stuff into own dub packages with a special "Phobos"
category
4) When compiler is released, provide snapshot of latest up to date
packages in that category as part of the distribution for those who
don't want to bother with fetching manually

This actually may be even possible to do within a linear deprecation
process. On the other hand I doubt such drastic change to structure is
possible to be sold to community.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161220/c464aedb/attachment.sig>