Hi,

> On 9 Jun 2024, at 19:18, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I would be surprised if "std::optional::transform" had any performance advantages at all in any scenario.

I use it all the time - multiple checkings shouldn’t be a problem if optimizer is working. OTOH, note that when you write ‘if (opt) { … }’, then there’s a sequenced-before relation even for parts that are not dependant on opt; whereas, if you are aware of runtime statistics (i.e., use it instead of exceptions), sometimes the builders producing the lambda passed to transform() might be such that there’s no sequencing between those and the evaluatiom of the ‘if’. This is a tiny bit in a special case of course. Also note that with .transform() you remain within an expression (thus might or might not have a prvalue), whereas with ‘if’, you need to duplicate code to feed the result to something that’s optimal for prvalue. Thus code cleaniness also dictates the transform pattern. Now, as wheter it needs to be within optional or become a named operator (e.g., |transformed_by>), or a free function, or a function applied to the lambda and producing another lambda, or anything else, that’s a different question.

Regards,
-lorro