Le 26/05/15 16:47, Niall Douglas a écrit :
On 26 May 2015 at 10:02, Lee Clagett wrote:
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? This monad is ridiculously simple because it's fixed function variant, and instantiates exactly two types per instance, and currently two free function overloads. No partial specialisations at all. There will be R& and void specialisations later, but they are all hash lookups, not shortlisting lookups in the compiler.
Expected instantiates dozens of types and functions per instance. Lots of partial specialisations too. All of that is very slow and involves lots of generating shortlists and iterating them for closest overload match. Slow.
IMO what is important is not is the implementation of Boost.Expected slow the compile time considerably (it is just a POC and can be improved a lot) but if the interface fores it. How can it be compared to the compile time while using optional? What I've observed is that making expected a literal type (constexpr evrywhere) resulted in compile time much slower. Now we have C++14, I'm sure there are others that have a better implementation. So the question is, do we have the proposed interface for expected, or something else? Would be the 'to be named type" a literal type? Vicente