On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote:
As per latest agreement everything in std.experimental is
considered subject to any change so is perfectly flexible.
- new drafting modules won't disturb usual users of the
standard library
That statements needs some hard data that current situation is
disturbing to be considered as a rationale.
If you put to many uncompleted modules in the std.experimental it
can influence stable part of the Phobos.
- binary size
- pull request with more experimental stuff
etc.
IMO, std.experimental is not for the drafting stage of the SW
development.
Depends on your definition of "draft". Anything that is good
enough to be actually used in real app is good enough for
std.experimental - and anything less is of no use to end user
anyway.
I agree that all is a matter of definition. I still doubt that
fast evolving drafts would be possible in std namespace.
2) what would it give over code.dlang.org ?
- community driven as opposed to individual driven
- out of the box readiness
- minimal fragmentation and controversy
code.dlang.org is actually much more community driven because
it is naturally decentralized. Controversy is inevitable anyway
(hello std.json).
I used the "community driven" in contrast to "individually
driven". The key property of the proposal is to minimize the
controversy by community (common) drafting process.
Fragmentation is a thing though - but I yet to be convinced
that is a bad thing that needs to be fixed.
I consider fragmentation a major problem for standards.
3) what problems are you trying to solve and why do you think
this is suitable solution?
Adding new modules (replacing the deprecated ones) in more
robust and quicker manner.
It is as quick as it can be for standard library - and
code.dlang.org takes care of everything else.
I have non-trivial modules in mind like gui, json, database, etc.
Any library that risks quick removal of deprecated modules /
API is not acceptable for "standard" stamp.
The drafting lib is a proposition of standard not a standard
itself.
And I didn't said anything about removal. I was referring to:
"Warning: This module is considered out-dated and not up to
Phobos' current standards. It will remain until we have a
suitable replacement, but be aware that it will not remain long
term."
So far this does not seem a proposal that pulls own weight to
me.
I can put the burden on my shoulders.
I'm in the middle of DIP creation. Unfortunately I have a regular
job and other duties. Still, I hope to finish it as soon as
promised.
Piotrek
