| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
|
|
Rename existing iterators to get rid of the Iterator suffix and to
give them names that better describe the things being iterated over.
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
|
|
|
|
There were a few ambiguous error messages which look like they could have
cropped up from either the rust compiler for the format string parser. To
differentiate, the prefix 'invalid format string' is now added in front of all
format string errors.
cc #9970
|
|
Instead of just saying "unterminated format string" and friends, instead print
information about what was expected and what was found.
Closes #9931
|
|
|
|
* Allow named parameters to specify width/precision
* Intepret the format string '0$' as "width is the 0th argument" instead of
thinking the lone '0' was the sign-aware-zero-padding flag. To get both you'd
need to put '00$' which makes more sense if you want both to happen.
Closes #9669
|
|
Closes #9824
|
|
Closes #9671
|
|
|
|
Closes #9119
|
|
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
|
|
Otherwise extra stuff after a lone '}' character is simply ignored, which is
very bad.
Closes #8938
|
|
|
|
See discussion in #8489, but this selects option 3 by adding a `Default` trait to be implemented by various basic types.
Once this makes it into a snapshot I think it's about time to start overhauling all current use-cases of `fmt!` to move towards `ifmt!`. The goal is to replace `%X` with `{}` in 90% of situations, and this commit should enable that.
|
|
By using a separate trait this is overridable on a per-type basis and makes room
for the possibility of even more arguments passed in for the future.
|
|
|
|
|
|
The new macro is available under the name ifmt! (only an intermediate name)
|
