Generality creep

[Jonathan M Davis]

On Thursday, March 28, 2019 12:47:49 PM MDT Andrei Alexandrescu via 
Digitalmars-d wrote:
> On 3/28/19 2:41 PM, Andrei Alexandrescu wrote:
> > On 3/28/19 2:30 PM, H. S. Teoh wrote:
> >> The only way I can see this happening is if we start a new iteration of
> >> Phobos, like std.v2.*
> >
> > There'd be carefully carved subsets per capability, such as
> > std.v2.betterc.*, std.v2.nogc.*, std.v2.noexcept.*, std.v2.safe.
> >
> > The capability sets can be combined in alphabetic ordering. E.g.
> > std.v2.noexcept.nogc.* has the subset that uses no gc and no exceptions,
> > but std.v2.nogc.noexcept does not exist.
> >
> > Through the magic of public imports and aliasing there would be no code
> > duplication. Introspection could help, too, a la "define public aliases
> > for all @safe definitions in that module". Some improvements to ddoc
> > might be needed to "see" through aliases.
>
> Oh, and druntime must go.
>
> The whole distinction between the runtime library and the standard
> library is clowny and has more to do with poorly ported tradition from
> other languages, than with anything else.
>
> We need one standard library that is entirely pay-as-you-go (e.g. empty
> main() means no library file is ever needed for linking) and that offers
> an opt-in continuum.

LOL. That's a big thing to drop in as an afterthought. There are some useful
organizational aspects of having druntime, but it has become a bigger and
bigger problem over time as we've tried to do stuff that's required to be in
druntime but which effectively requires stuff that's in Phobos - a long
standing example of that being UTF encoding and decoding. AFAIK, there are
still a number of hurdles to truly making it pay-as-you-go, but if we can do
it, it would be great.

This would also be a great opportunity to fix some of the issues with shared
in druntime (in particular with the mutex and conditional variable stuff as
well as Thread). Too much of it doesn't use shared properly (if at all), and
in the case of Thread, it has @safe functions that end up passing
thread-local objects to a new thread, which would be much easier to do with
something like v2 or moving all of that to std (certainly, there are things
that should be fixed there that we can't fix in-place).

All in all though, I think that we're going to have to plan carefully with
how we go forward with major changes like this so that we minimize the risk
of splitting the community. With D's module system, we have a lot of
flexibility, but when we start replacing core code and concepts with new,
incompatible versions in separate modules, we do risk compatibility
problems. However, full-sale replacement of some modules would definitely
fix some of the issues that replacing stuff in pieces within a module has.

- Jonathan M Davis