On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei
Alexandrescu wrote:
I was looking at
https://github.com/D-Programming-Language/phobos/pull/3765 and
whilst it's a sensible addition, I'm thinking we'd want to pass
it and all other library additions through std.experimental
first. So we'd have a std.experimental.range package that would
be a purgatory for things to be added to std.range, and so on.
We have examples from the past when additions that seemed
obvious and sensible needed a few tweaks before stabilization.
Going through std.experimental seems like a good approach to do
such.
What say you?
I don't know. It probably makes sense for some stuff, but in
other cases, the fact that it ends up in a module other than its
target module could be problematic (especially when overloads
come into play). It also seems like extra red tape and extra
effort that's then going to have to be spent moving symbols
around. On the other hand, it would at least potentially help
catch some problems.
Regardless, we need to make it clear how we're going to move
stuff from std.experimental to std, and what the timetable for
that is supposed to be. AFAIK, thus far, we've never moved
_anything_ from std.experimental to std. In the case of new
modules, are we supposed to vote on them again before actually
moving them into std? Do they just get moved over after they've
been around for a certain period of time? Or is it some other
criteria? And if we start putting new symbols in
std.experimental, should those same criteria apply to individual
symbols in addition to modules? Having another vote before
migrating a new module might make sense, but that's definitely
overkill for a new symbol. And new symbols probably don't need
the same kind of bake time that a new module would. Right now,
AFAIK, we have no policy with regards to std.experimental at all
except that that's where new modules are supposed to go when they
get voted in.
- Jonathan M Davis
