Primary Ranges of Containers

[Matthias Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/18/2012 01:08 PM, Jonathan M Davis wrote:
> On Monday, June 18, 2012 10:06:44 Matthias Walter wrote:
>> Hi,
>> 
>> last week I realized that a const version of 
>> std.container.Array.opSlice() is missing. Now I looked at the
>> code and I think that it is a general design problem.
>> 
>> The docs state that "c.Range" is "The primary range type
>> associated with the container.". I think we really always need
>> two Range types (one for const view and one for non-const view)
>> by design.
>> 
>> I'd propose to always add a bool template parameter (maybe
>> isConst?) to the range since most of the write-functionality can
>> be "removed" by a static if statement in order to make the range
>> read-only.
>> 
>> Any suggestions?
> 
> Yeah, it'll probably have to be templated. C++ already has to do
> something similar with iterators and const_iterators. But since you
> don't normally use the type of a range explicitly, it shouldn't be
> a big deal. The one downside that might pose a problem though is
> that if someone _does_ use the type explicitly, their code will
> break if the type gets templated. We could make a second type
> (ConstRange?) for the iterating over a const Array, but I'd be 
> tempted to just templatize the thing and let it break any code that
> it breaks. std.container is already likely to break stuff to at
> least some extent when the custom allocators get added anyway. I
> suppose that we could just rename the type and then create an alias
> for the current type
> 
> struct ArrayRange(bool isConst) {...} alias ArrayRange!false
> Range; alias ArrayRange!true ConstRange;
> 
> but that might be overkill. I don't know. Regardless, it _is_
> likely that the range type will have to be templatized to fix the
> problem. Ranges and range- based functions in general need to be
> cleaned up a bit to deal with const, since the way that they're
> designed doesn't work with const very well, and we need to make it
> work. I think that it _can_ work, but it takes more effort to do
> so.

I fully agree with all that. In order to migrate older code we may
make isConst have a default value of false.

Best regards,

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP4B8OAAoJEPdcuJbq5/sR7h0H/jeJ+KPUMoiP9SqiamE0qv4V
IantID2fzML8b55CWGQ2ZU7YbhQqOPIIEVtRriNAUIA4sHqWXQA03YgFrDk7XZZy
jrhx9VCUkiMeIuHhSdXQIwAWH+dkfnQoOS9EwbbiwZjBG+zU5iH/s9tduRzKadTr
Bb4QLAx7hEjlsvgRArj0O5z88YeGWbLhUzTz70utoE+1VgROuVF4WzJL9S803ZWX
ZZR1HOx0ktE60jvBTMoK2TzSfB5/JjiDQSWjK8ikEQGSw8QR3M3DWD3WkFucOAaL
3K6xH/yoDTBMOT+IVjkfVOsnv0iBB7ARpJKxOD2r+bJOoGWCQ1YQAoyY8rwrez0=
=yhaM
-----END PGP SIGNATURE-----