On Saturday, May 05, 2012 18:57:05 David Nadlinger wrote: > The title says it all – currently, std.array.array() is broken > for (some) ranges of const/immutable elements. Fixing it is not > hard, but the question is: Should it always return an array of > (head-)mutable elements (since it allocates a copy anyway), or > should it preserve constness of the element type? > > The latter is maybe be the more »consistent« behavior, as the > return type would always just be ElementType!Range[], but has the > disadvantage that if you actually wanted to construct a mutable > array from an immutable range, you'd have to cast away immutable > (with unclear semantics), whereas getting an immutable array with > the first implementation would just require assumeUnique() (for > most ranges, array() is not going to be strongly pure). > > I have a fix ready, but will hold back the pull request until it > is clear which semantics we want.
I think that std.array.array should return an array of exactly the same element type as the range that was passed to it. If those elements are const or immutable in the range, then they're const or immutable in the array. What _would_ be valuable would be for std.array.array to have another template parameter allowing you to indicate the element type of the array (and which worked with type which the original element type was implicitly convertible to, with the possible addition of making char and wchar arrays work with ranges of dchar). Naturally, it would default to the exact same type, but it would allow you to get an array of varying constancy without dup, idup, or casting. - Jonathan M Davis
