http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

  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.

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?

On 9/16/2010 4:31 PM, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

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

  On 9/16/2010 7:43 PM, Andrei Alexandrescu wrote:
> 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?

For supporting const/immutable ranges, I've come to the conclusion that we should start putting Unqual everywhere so that at least ranges with a natural tail const (arrays, ranges w/o any indirection) work with zero hassle.  This wouldn't be a perfect fix, but it would cover a heck of a lot of important cases.  BTW, const/immutable arrays currently work in a lot of places where they shouldn't (http://d.puremagic.com/issues/show_bug.cgi?id=4877) and I dread having to fix all the code that relies on this bug after it's fixed.

Also, as far as supporting ranges of const elements, I wonder if we could extend Rebindable into a general but limited tail const.  We'd probably need something like this unless we want to have to use unsafe casts all over the place inside std.range and std.algorithm.  I'll probably post on the newsgroup when I work out the details in my head, but so far the only issue I see is dealing with structs with elaborate copying/assignment, though this is a huge one.