Am 11.08.2015 um 19:08 schrieb Atila Neves:
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
I forgot to give warnings that the two week period was about to be up,
and was unsure from comments if this would be ready for voting, so let's
give it another two days unless there are objections.
Atila
I think we really need to have an informal pre-vote about the BigInt and
DOM efficiency vs. functionality issues. Basically there are three
options for each:
1. Keep them: May have an impact on compile time for big DOMs (run
time/memory consumption wouldn't be affected if a pointer to BigInt is
stored). But provides an out-of-the-box experience for a broad set of
applications.
2. Remove them: Results in a slim and clean API that is fast (to
run/compile), but also one that will be less useful for certain
applications.
3. Make them CT configurable: Best of both worlds in terms of speed, at
the cost of a more complex API.
4. Use a string representation instead of BigInt: This has it's own set
of issues, but would also enable some special use cases [1] [2] ([2] is
also solved by BigInt/Decimal support, though).
I'd also like to postpone the main vote, if there are no objections,
until the question of using a general enum based alternative to
Algebraic is answered. I've published an initial candidate for this now [3].
These were, AFAICS, the only major open issues (a decision for an opt()
variant would be nice, but fortunately that's not a fundamental decision
in any way). There is also the topic of avoiding any redundancy in
symbol names, which I don't agree with, but I would of course change it
if the inclusion depends on that.
[1]: https://github.com/rejectedsoftware/vibe.d/issues/431
[2]:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/10098/
[3]: http://code.dlang.org/packages/taggedalgebraic
