diff options
| author | Alex Burka <aburka@seas.upenn.edu> | 2016-01-13 13:12:16 -0500 |
|---|---|---|
| committer | Alex Burka <aburka@seas.upenn.edu> | 2016-02-27 02:01:41 -0500 |
| commit | 24cc90262bd5ec52aa421103ef7c89a0697b046d (patch) | |
| tree | 8184668622741faa62a24660cf57433ab81a8337 /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 15a8a296b724599a1eda807c3057338b11cb94bf (diff) | |
| download | rust-24cc90262bd5ec52aa421103ef7c89a0697b046d.tar.gz rust-24cc90262bd5ec52aa421103ef7c89a0697b046d.zip | |
note work still to be done
In particular, uses of inclusive ranges within the standard library are still waiting. Slices and collections can be sliced with `usize` and `Range*<usize>`, but not yet `Range*Inclusive<usize>`. Also, we need to figure out what to do about `RangeArgument`. Currently it has `start()` and `end()` methods which are pretty much identical to `Range::start` and `Range::end`. For the same reason as Range itself, these methods can't express a range such as `0...255u8` without overflow. The easiest choice, it seems to me, is either changing the meaning of `end()` to be inclusive, or adding a new method, say `last()`, that is inclusive and specifying that `end()` returns `None` in cases where it would overflow. Changing the semantics would be a breaking change, but `RangeArgument` is unstable so maybe we should do it anyway.
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
