On Monday, 4 June 2012 at 22:22:34 UTC, Roman D. Boiko wrote:
On Monday, 4 June 2012 at 22:06:49 UTC, Dmitry Olshansky wrote:
On 05.06.2012 1:56, Roman D. Boiko wrote:
so range API doesn't fit that (but could with a tweak -
returning tail instead of mutating in popFront). If trie API
will have similar problems, then I need to invent my own. I
understand that immutability is not your priority for GSoC,
though.
Well I might remove obstacles, if you outline your design more
clearly.
OK, thanks! I'll go through your code first to understand it
better. But even before that I need to finish an important
support request from my past customer...
Basically, the most important aspect of immutability is returning
a new instance of data structure on each insert / delete /
update, and keeping the old one unchanged, instead of performing
update in-place. This may not fit your most common use cases,
though. Would be great to enable such semantics via policies, but
without deep analysis I can't come up with a good API / design
for that (without overcomplicating it). Probably keeping mutable
and immutable APIs separate is the best choice. Will return to
this problem once I get a bit of free time.
