|
I think that covers all the known bugs in std.range and std.algorithm,
with the following exceptions: 1. Enhancement requests, as opposed to "real" bugs. 2. Pure documentation issues. 3. Stuff related to static arrays. 4. Bug 3067, which is really a compiler bug. How do we want to handle the static array case, long term? IMHO stuff in std.range and std.algorithm should generally not support static arrays because in addition to being a PITA to implement, since static arrays are usually stack allocated, using them as ranges is inherently unsafe. Even in cases where it seems safe, the predicate may do weird things like escape the static array. In non-generic code using [] to explicitly make the array into a range isn't much of a problem. I think the generic programming issue can be solved by simply having an unsafe function in std.range. This would make it easy to make static arrays work with generic programming but require making the conversion somewhat explicit. It would look something like: auto toRange(R)(ref R stuff) if(isInputRange!R) { static if(isStaticArray!R) { return stuff[]; } else { return stuff; } } Of course, I'd also create an overload w/o the ref so it works with rvalues. Comments? On 8/16/2010 10:56 PM, dsource.org wrote: phobos commit, revision 1884user: dsimcha msg: Bug 4408: Ambiguity when using std.algorithm.splitter with generic ranges http://www.dsource.org/projects/phobos/changeset/1884 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos |
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
