On Tuesday, 2 October 2012 at 16:59:38 UTC, Jonathan M Davis
wrote:
On Tuesday, October 02, 2012 18:45:50 Peter Alexander wrote:
On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas
wrote:
> On 2012-10-02, 18:09, Peter Alexander wrote:
>> On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
>>
>> wrote:
>>> If you've ever worked on a template that needs to index a
>>> range, you may have run into this problem: What is the type
>>> you should use to index an RA range?
>>
>> Forgive my ignorance. What's wrong with size_t?
>
> That not all ranges use it? If the range uses int, short,
> byte
> (I wonder why they'd do it, though), using size_t will not
> even
> compile.
That's kind of my point. Unless there's a compelling reason not
to, I'd suggest we standardise on size_t indexing (and length)
and avoid this issue altogether.
C++ containers have a size_type typedef. No one uses it.
Let's keep things simple instead of complicating things for the
sake of unwanted "flexibility".
In general, all ranges _should_ use size_t for both length and
indexing, but
for a few range types in Phobos specifically use ulong (e.g.
IIRC iota does in
order to work properly with ranges or long and ulong on 32-bit
systems). I see
_zero_ reason to support lengths or indices smaller than
size_t. Types that do
that are badly designed IMHO. But we already have a precedent
that you can't
always assume size_t (at least for length - I'm not sure about
indices - but
if length can be specifically ulong and the type is random
access, then its
indices will need to be ulong), so unfortunately, the situation
is not so
simple that you can always assume size_t (even you should
arguably be able
to).
- Jonathan M Davis
Given your stance of "I see _zero_ reason to support lengths or
indices smaller than size_t" and "Types that do that are badly
designed IMHO":
Are you agreeing with my proposed type tightening? If anything,
it weeds out the "bad designs" for which you had no wish to
support, while allowing better support for those that do.
