On 27 Aug 2015 at 15:31, Vinícius dos Santos Oliveira wrote:
Anyway, maybe I can help here. I know Niall had played with Rust for sometime[1] (and end up eventually hating for the lack of an asynchronous foundation[2]). I too end up playing with Rust for some time and maybe that's why I understood Niall without trouble.
Hating is far too strong a word. Rust's standard i/o library can't do select() on sockets and instead forces you to spin up a dedicated kernel thread to sit around waiting for reads, and then provides no way whatsoever of poking we-are-about-to-shutdown at that dedicated thread. I got very frustrated working around that, as would anyone. We're not stuck in the 1970s for god's sake. Rust's standard i/o library is close to useless for real world portable programming, that's all. They know this, and this time next year they'll have a vastly improved standard i/o library.
Anyway, a value that was consumed is a value that cannot be used again. There are consuming operations that will consume the value. It's closely related to the move idea, where the moved value is left in an unspecified state. There are moving operations and there are consuming operations, but consuming operations work on values other than rvalues too.
Imagine a range that invalidates the original container. It *consumes* the container.
Does that explanation help?
Remember that Hartmut and Thomas are coming from a standards-ease perspective, and hence their disavowal of thinking in terms of anything not termed in standards-ease. You may not be aware Vinícius that Hartmut is a world leading expert in concurrency, and is one of the main minds behind the Concurrency TS. I in the meantime don't really care much about design purity - if I did I would not write in C++. I do care about impure design causing users to write dangerous code which will fail in unexpected ways, and to that end consuming futures are usually superior. However in AFIO's case the thing being transported with non-consuming semantics is a shared_ptr, and both that and the handle it reference counts is thread safe. This, as far as I can tell, eliminates any chance for dangerous code being written by end users and is why I allowed that design choice and it does save significant additional typing to be written by end users. But in the end, I'm no world expert on concurrency. I mostly design by instinct not logic. My design choices are famously mongrel as a result as you can see in afio::future<T> having dual future semantics, one for the handle, the other for the T. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/