On Mon, May 25, 2015 at 10:51 AM, Niall Douglas
On 25 May 2015 at 8:27, Rob Stewart wrote:
The idea has merit, but I have some concerns. The best practice you've linked states that there are problems with Boost.Threads' expected type, but you only mention compile times specifically. I'd like to better understand why expected cannot be improved for your case. That is, can't expected be specialized to be lighter for cases like yours?
I am one of few here who has seen Expected deployed onto a large code base. The other guy is Lee, who has even more experience than I do. Ours was not a positive experience in a real world large code base use scenario.
My experience with Expected was positive in that codebase. However, I really don't care about compile times, and would often switch between machines after requesting a build (so I rarely knew how long it would take). I did have a header-heavy portion (using ASIO stackless), and I know that test file took a noticeable amount of time to compile. I don't know how much was related to Expected. I recall other files, with less header-heavy code, being much more reasonable. These files were also under 300 lines each. The number of macro switches in Expected was the concern for me, which could be reduced if C++14 only compilers were supported. Also, in terms of it now being 2015, we know WG21 are working on an
official variant type - it was the talk of C++ Now. Such a variant is an obvious base class for any expected implementation rather than reinventing the wheel separately.
Similarly, the future-ishy parts of expected would make more sense to come from a base future-ishy type which is then composed with a variant type to make an expected type which does all the singing and dancing anyone could desire. That means rewriting expected from scratch sometime later on.
I've read through the remainder of this thread - are you hoping to replace use-cases of Expected with this new future_result type? So that a codebase would use this one type for future and immediate related results? Synchronous functions could be made asynchronous without changing the API, which is an interesting property. But if the major complaint about Expected is the compile-time, what is causing that compile-time, and how will this new type avoid that? Lee