On Saturday, 3 June 2017 at 06:37:27 UTC, H. S. Teoh wrote:
On Sat, Jun 03, 2017 at 02:16:16AM +0000, Adam D. Ruppe via
Digitalmars-d wrote:
On Friday, 2 June 2017 at 20:37:05 UTC, H. S. Teoh wrote:
> Especially the bit about throwing away years of accumulated
> programming work.
Our IRC discussion was more about simplifying the Phobos
interface through breaking changes than actually just dropping
and rewriting. Most the "phobos 2" would just be today's
phobos with mistakes changed, autodecoding deprecated then
removed, eager functions same deal (the discussion that
started it was split vs splitter), static array interfaces
removed (you'd have to explicitly slice at the call site
instead of Phobos trying to two-layer ref them), etc.
So step one of this would be to copy existing code. Then cut
the mistakes out.
The modified modules are just given a new package name (or
something)
to ease the transition.
Now that you put it this way, this suddenly seems a lot less
disruptive and intimidating than it first sounded.
And it sounds more possible to actually use the deprecation
cycle to gradually pull this off, as opposed to throwing out
the baby with the bath water and restarting from ground zero.
And by putting the modified modules in a new temporary
namespace, we can ease the transition enough that perhaps we
might actually see this happen, one day. (Haha, so I hope.)
T
Same will there come to be a need to replace Phobos 2 (when it
happens) with 3 all because we prefer things to be renamed and
relocated... when we've not fully discovered what phobos
currently offers or improvements to be made.
stdx.data.json was not well documented last time I checked.
Couldn't see any major benefit over std.json besides the
performance claim. Besides, phobos is an MVP, there are more
faster dub packages and nothing stops u from using them.
Does it really matter if it belongs in the std namespace?