On 09/16/2010 06:01 PM, David Simcha wrote:
Basically works for me. There is one issue, though, that I don't think
is a showstopper for this release but highlights a very bad long-term
issue that I'd really like to address sooner rather than later.
In Phobos right now, you can no longer do lowerBound, canFindSorted,
etc. on a const/immutable array due to 3 bugs in SortedRange. Two of
these are trivially fixable (look at the code for save() and opSlice())
but the third isn't. release() calls move() on the range. This doesn't
work for const/immutable arrays.
This is also easy to fix by guarding release() with a static if.
In general bug reports are piling up in Bugzilla about how defective
std.range and std.algorithm are when dealing w/ const/immutable ranges
and elements. D's lack of tail const makes this essentially impossible
to deal with on a generic level (though for arrays specifically the fix
is trivial, but I don't want to just special-case things in supposedly
generic code). This is an entire class of bugs that we just don't know
how to fix. Ideas?
I think we should focus, at least initially, on non-constant ranges of
constant elements. Algorithms expect to mutate their ranges, it's mostly
how the whole thing works. So we care about ranges of const elements,
and I don't think we're helpless with those because many ranges are
templated on their element type a la SomeRange!(const X).
One step forward for const arrays is to do make typeof(arr[]) const(T)[]
when typeof(arr) is const(T[]). Same with immutable. That way, people
who have const and immutable arrays only need to append "[]" to their
array when passing it to some std.algorithm function.
Walter, what do you think?
Andrei
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
