On 10/01/2016 05:30 AM, Lodovico Giaretta wrote:
On Saturday, 1 October 2016 at 02:31:23 UTC, Andrei Alexandrescu wrote:
https://github.com/dlang/phobos/pull/4827 still allows that but
specifies that phobos algorithms are not required to. -- Andrei
I don't have much experience, but IMHO the length should be restricted
to be any of the built-in unsigned integral types (ubyte, ushort, uint,
size_t, ulong). This way, all comparisons for equality or inequality are
defined and correct, and the common type exists and is the one you'd
expect. Also, every other operation on them works as expected, because
smaller types are widened and the absence of signed types guarantees no
strange results.
I've looked through phobos and sizes smaller than size_t present less
risk. The issue is that e.g. code is liable to do:
auto len = r.length;
and the proceeds to use len tacitly assuming it's a size_t. If r.length
were allowed to return e.g. ubyte, doing something like ++len may
overflow a lot earlier than the code would expect.
I made a quick pass through Phobos looking for potential issues. I found
a couple in replaceLast (uses arithmetic on indexes obtained with auto)
but not much else (in fairness I stopped at std/file.d in whatever order
"git grep" lists files).
So in all likelihood sizes smaller than size_t may be easier to make
work. However, this seems to complicate definitions without a
corresponding payoff. For example a natural consequence would be to have
operator[] take the same type as the length. That would definitely cause
problems because people pass index computations to operator[] such as 1,
idx + 1, or $ - 1.
The only problem that arises with this definition of length is that
functions cannot take a length parameter as size_t, because that could
truncate it.
I think Jonathan is right: sizes longer than size_t have numerous issues
- in fact enough that the limiting decision was made (by a group of
contributors and approved by us) to force iota.length to return size_t.
Andrei
