
Paul wrote:
For this review, I doubt if we should worry too much about *current released* compiler's performance. If Outcome becomes popular, we can expect compiler optimisers to focus their attention on optimising Outcome.
Outcome only targets very recent compilers because of performance, doesn't it? i.e. One of the reasons cited in another mail for dropping MSVC2015 (i.e. the second newest MSVC version) in favor of only supporting MSVC2017 is that the former generates suboptimal code for this Outcome implementation. Did I misunderstand that? i.e. If you're talking about the next major compiler version release from this particular vendor, what motivation is there to optimize for usage of Outcome, when they will probably already provide their own optimal expected<T, E> implementation? At that point, would there be a need for Outcome for those users who are just after an expected<T, E> implementation, and are already going to upgrade to a standard library implementation that provides a more optimal std::expected? I would have thoguht current compiler performance is important for that reason. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Outcome-review-First-questions-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.