[ 2017-06-24, Daniel comments and provides wording ]

The wording changes below are supposed to support all moneyT types that are convertible to either long double or to money_put/get<Ch, o/istreambuf_iterator<Ch, Tr>>::string_type (but not to both), where Ch and Tr are determined by the concrete instantiated specialization of the exposition-only function template f that is used to specify the semantics of put_money and get_money, respectively. XOR-ing the requirements outlaws types that are convertible to both, which would cause an ambiguity unless we would provide wording that would introduce an ordered application of these convertibility constraints. This is the rationale for the seemingly odd new Remarks formulation. Note also, that the wording provided below intentionally attempts to distinguish between the statically testable conditions based on the is_convertible_v expressions within the Remarks: element and the well-defined runtime behaviour requirement of the actually provided argument of deduced type moneyT within the pre-existing Requires: element. Another point worth pointing out is that the wording attempts to fix an currently existing ambiguity of the meaning of the type moneyT (and to a lesser extend for charT and traits) as either the template parameter of put/get_money or that of the corresponding template argument of the exposition-only f templates. The revised form makes it clearer that it refers to the latter.

It should be emphasized that this extension of the current wording would provide support for put_money(99), put_money(99.), and put_money("99"), but not yet for put_money(string_view{"99"}), because string_view is not convertible to string. To realize support for the latter, this wording approach could be extended by referring to is_constructible instead of is_convertible, though.