[dmd-beta] Hopefully the last betas
David Simcha
dsimcha at gmail.com
Thu Sep 16 18:05:42 PDT 2010
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.
More information about the dmd-beta
mailing list