grauzone wrote:
I'd remove from Phobos:
std.
openrj
bigint (old one, by Janice)
regexp
socket
xml
much, much more (see more complete list in my previous post[1]).
and suggest/force users use tango instead.
std.
zip
signals
outbuffer (there isn't even inbuffer, whee)
boxer (I like it, but Variant seems to supersede it)
cover (highly compiler specific, why is it in the stdlib?)
Also, the following modules really belong into core:
std.
atomics (contains intrinsics for atomic asm instructions, right?)
intrinsics
variant (come on!)
complex
bind
bigint
For bigint, only the low-level O(n^2) functions, I think. A bigint
implementation might use O(n lg n) fourier transforms for multiply when
the numbers get big enough -- that's far too heavyweight for the core, I
think. The low-level functions are almost intrinsics -- bigint add is
essentially the "add-with-carry" instruction, for example.
Also std.cpuid (without toString()).
All those modules (except complex, maybe) are things which you'd have to
rewrite when creating a new compiler, so I think using core for them is
reasonable.
Next steps:
- unify the C import modules
- move modules like std.range into core (magically enables Tango to use it)
I think you'll find Tango eventually wants to use most of the new Phobos
-- you'd find everything in std gets moved into core! So I don't think
range belongs there (unless the range struct gets built into the compiler).
- find a common I/O API (and put it into core), which wraps Tango/Phobos
specific I/O APIs (personally, I'd prefer having something simple like
std.stream [without the interfaces], instead of the clusterfuck in Tango)
PS: It's fine if it's a third stdlib, as long as both Tango and Phobos
people agree on it. It's too late anyway, and important, user-visible
types like Thread are in core.
The I/O is difficult. I think it's a legitimate design difference
between Tango and Phobos -- we're probably stuck with it. I think it'd
be better to leave it aside, and concentrate on unifying the simple stuff.
