On Monday, 2 February 2015 at 22:18:59 UTC, Piotrek wrote:
On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic
wrote:
I think std.experimental should essentially be its own
library, with its own slot next to phobos on the github repo.
I'm open to changing the name or something... but if we have
both std.experimental *and* your new mars, what do you think
is the real difference? How can std.experimental be "sort of"
experimental, but really not, whereas mars is "really
actually" experimental? Where is the cutoff line? How would
anyone know whether they reached it or not?
Hard to admit but I thought about removal of std.experimental
;), then I tried to find a better solution (not sure I did).
After all I don't want to make more enemies than I have.
So I got an idea that std.experimental can be adopted for the
piloting new modules into Phobos when approved to be a standard.
I'm arguing from the perspective that the approval must come
first, and the piloting second. Who would want to develop a
module in the "pre-pilot" phase, without having any idea of
whether they were developing it finally for phobos or just
3rd-party use, then wait months or years to find out if the
leadership is even *interested* in what they're doing? Why would
people try to meet high standards without knowing if those
standards are actually going to be required or not? It's like an
unpaid internship: "Work for us for free, and we'll let you know
at the end whether we want your work or not."
I'd even make one more point, that all current phobos modules
known to be in need of revamping be copied wholesale in their
current forms to std.experimental, with the top documentation
saying, "This is the experimental version of the old std.xxx,
which needs *your* help with its redesign and implementation.
Feel free to break the current API by improving it. This is
*not* currently considered a stable module."
Haha, let's not lose our nerves :) It's not that bad. Moreover.
I can barely find the equivalent level of code awesomeness as
it is in D libraries. We just need to speed up the progress and
reduce work fragmentation.
It occurred to me that when copying a module to std.experimental,
the documentation at the top of the original std module should
say, "This module has been feature frozen while work on the new
one continues at std.experimental.xxxx. The API for this module
will not break, nor will it be improved. Please consider using
std.experimental.xxxx and giving feedback for its design, since
eventually this module will be replaced with that one."
I do realize that this is kind of what happened with D1 and D2,
of course. Now you're going to have competing modules, and some
people won't want to give up on the old one. So you will have to
deprecate every change that breaks the old API first before
finally replacing it with the new one. Well, it's a hard problem,
and yet, "Most D code has yet to be written." But then again, I'm
not the one who has to take fire for breaking people's old code,
and I don't know if my attitude would change if I were.
