@RobertLeahy , please fix the sanitizer warnings.

Note that you can run the checker manually using ../tools/check-output.sh and ../tools/check-source.sh

Please add a "Fixes" line enumerated the NB comments addressed to the commit description.

Right, so the commit message should be:

P2505R5 Monadic Functions for std::expected

Fixes NB XX-123 (C++23 CD).

etc., and "2022-11 LWG Motion 13" is how I'll label the merge commit.

Thanks for this, @RobertLeahy!

Note that you can run the checker manually using ../tools/check-output.sh and ../tools/check-source.sh

Thanks for this, my latest push has only two sanitizer issues which I'm looking into:

::error file=utilities.tex::Overfull \hbox (21.47356pt too wide) in paragraph at lines 9470--9475
::error file=utilities.tex::Overfull \hbox (21.47356pt too wide) in paragraph at lines 9497--9502

I've resolved one of these errors with \allowbreak but it results in this:

I'm not sure whether we consider that acceptable or not. If it is I can resolve the other in the same way and repush.

You could try std::for\-ward, or transforming the code span into a code block.

std::for\-ward works:

Is this considered a better result than the \allowbreak result?

I had a draft comment on the issue (#5974) that I'll post here:

Contrasting the wording in the paper for std::expected::transform with the wording for std::optional::transform I notice that:

• Wording for std::expected::transform is missing "for some invented variable u"
• Is missing the note that there's no requirement that U be movable

Is this considered a better result than the \allowbreak result?

I think so. My impression is that there's a preference for breaking mid-word rather than at symbol-word bounds. There's a number of examples for exactly this case:

$ grep 'for\\-' *.tex
containers.tex:from \tcode{piecewise_construct}, \tcode{for\-ward_as_tuple(k)},
containers.tex:from \tcode{piecewise_construct}, \tcode{for\-ward_as_tuple(std::move(k))},
containers.tex:assigns \tcode{std::for\-ward<M>(obj)} to \tcode{e.second}.
containers.tex:from \tcode{std::move(k)}, \tcode{std::for\-ward<M>(obj)}.
containers.tex:assigns \tcode{std::for\-ward<M>(obj)} to \tcode{e.second}.
containers.tex:from \tcode{k}, \tcode{std::for\-ward<M>(obj)}.
containers.tex:assigns \tcode{std::for\-ward<M>(obj)} to \tcode{e.second}.
containers.tex:assigns \tcode{std::for\-ward<M>(obj)} to \tcode{e.second}.
ranges.tex:  each model \libconceptx{for\-ward_range}{forward_range}, then \tcode{iterator_concept} denotes
ranges.tex:then \tcode{iterator_concept} denotes \tcode{for\-ward_iterator_tag}.
threads.tex:\tcode{invoke(auto(std::forward<F>(f)), auto(std::for\-ward<Args>(args))...)}\iref{func.invoke,thread.thread.constr}
threads.tex:\tcode{auto(std::for\-ward<Args>(args))...}
utilities.tex:with \tcode{std::for\-ward<Args>(args)...}.
utilities.tex:\tcode{ilist, std::for\-ward<Args>(args)...}.

Hi, found a minor issue... std::forward is missing the 'f' argument for one of the or_else definitions:

Thanks

Is this considered a better result than the \allowbreak result?

I think so. My impression is that there's a preference for breaking mid-word rather than at symbol-word bounds.

Thanks - yes, I agree, I think it can be quite confusing to have symbols and puncutation break across lines, whereas a break in the middle of a normal word is a bit more normal and expected and easier to follow.

Great work; many thanks, @RobertLeahy!