Had a conversation with @cmr in IRC about some places that these
docs were confusing. The functions that advance the stream now say so.
In addition, I think that calling out the similarities to familliar C
functions should help people coming from other languages.
My earlier fix for #4202 would not work correctly if the trait being exported was a top-level item relative to the module from which it was being exported. An example that would not work correctly with the original patch:
// foo.rs
pub use Foo = self::Bar;
pub trait Bar {
pub fn bar() -> Self;
}
impl Bar for int {
pub fn bar() -> int { 42 }
}
// bar.rs
fn main() {
foo::Foo::bar()
}
This is now supported.
I believe this change will allow the GenericPath trait to be exported from core::path as Path in such a manner, which should allow #5389 to move forward.
Had a conversation with @cmr in IRC about some places that these
docs were confusing. The functions that advance the stream now say so.
In addition, I think that calling out the similarities to familliar C
functions should help people coming from other languages.
I don't have a strong opinion on the function vs. method, but there's no point in having both. I'd like to make a `repeat` adaptor like Python/Haskell for turning a value into an infinite stream of the value, so this has to at least be renamed.
I don't see a reason to encode this information in all the `extern mod` statements, it's not a precise enough version to actually provide any sort of robustness.
r?
This is all of my scheduler work on #4419 from the last 3 weeks or so. I've had a few failed pull requests so far but I think the problems are ironed out.
* TCP
* The beginnings of runtime embedding APIs
* Porting various corners of core to be compatible with both schedulers
* libuv timer bindings
* Further refinement of I/O error handling, including a new, incomplete, `read_error` condition
* Incomplete refactoring to make tasks work without coroutines and user-space scheduling
* Implementations of Reader/Writer extension methods
* Implementations of the most important part of core::comm
I'm particularly happy with how easy the [comm types on top of the scheduler](https://github.com/brson/rust/blob/io-upstream/src/libcore/rt/comm.rs). Note that these implementations do not use pipes. If anything here needs careful review though it's this code.
This branch passes 95% of the run-pass tests (with `TESTARGS=--newrt`)
In the next week I'll probably spend some time adding preliminary multithreading and seeing how close we are to removing the old runtime.
* The example given in future.rs was corrected.
* I have added a small section describing futures in tutorial on tasks. It is far from being complete as I am stil learning !
(This is an updated version of PR 6537).
This commit implements element getters for tuples with an arity of 2 to 12. The getters return references to the elements, so no copying occurs. The traits are re-exported in `core::prelude` so you can use them from regular Rust code.
Here is an example of one of the getters in use:
~~~rust
assert_eq!((2, "hi", 75.0).n1(), &"hi");
~~~
