On Sun, Apr 5, 2026 at 2:17 PM Charles R Hogg <charles.r.hogg_at_[hidden]>
wrote:

>
>
> On Thu, Apr 2, 2026 at 2:59 AM Lénárd Szolnoki via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On 2 April 2026 06:14:10 BST, Jan Schultke via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> >While the idea is is worth pursuing, extensible math functions would be a
>> >lot of design work that cuts horizontally across several proposals:
>> >
>> > - P3935R0 "Rebasing <cmath> on C23" adds many more mathematical
>> > functions.
>> > - P3045R7 "Quantities and units library" also mentions mathematical
>> > functions that operate on quantities.
>> > - I forgot the number ... we had a proposal that lets you explicitly
>> > specify rounding modes for math functions I believe.
>> >
>> >I suspect that if we were to add quantities and units to the standard
>> >library, then new mathematical functions will be part of that library in
>> >some way. Being able to std::floor a second or meter or something is a
>> >major motivating use case. You should get in touch with the authors and
>> see
>> >how much overlap there is.
>>
>> The last thing I want is a single argument std::floor that silently
>> returns semantically different quantities when called with meters or
>> centimeters.
>>
>> I'm fine with pow and sqrt (which is a special case), but not a lot of
>> other math functions are viable outside of dimensionless quantities.
>>
>
> This is exactly right, and thank you for recognizing and articulating this
> critical principle.
>
> In the Au units library, we have "floor_as(units, q)" (returning a
> quantity) and "floor_in(units, q)" (returning a raw number). You must
> always name the unit at the callsite. See the docs
> <https://aurora-opensource.github.io/au/main/reference/math/#floor> for
> more details.
>
> I assumed mp-units did the same, because they are usually excellent about
> unit safety. However, I was alarmed to find that they somehow seem to be
> back to a single-argument version
> <https://github.com/mpusz/mp-units/blob/master/src/core/include/mp-units/math.h#L335-L349>.
> I reopened the issue
> <https://github.com/mpusz/mp-units/issues/432#issuecomment-4189300262>,
> and I hope it gets resolved promptly.
>

Just updating to say: this was my misunderstanding. mp-units uses a
*template* parameter to specify the unit. So the interface actually *is* unit
safe. That definitely makes a lot more sense!


>
>
>>
>> >
>> >On Wed, 1 Apr 2026 at 23:19, Stéphane Gros-Lemesre via Std-Proposals <
>> >std-proposals_at_[hidden]> wrote:
>> >
>> >> Hello,
>> >> It is my first time posting here, I'm not sure I am following the
>> proper
>> >> process. Please let me know if I'm doing this wrong.
>> >>
>> >> I wanted to float here this idea, see if there would be interest.
>> >> The idea is providing an extension mechanism for std math functions.
>> >>
>> >> The idea is presented here:
>> >> https://github.com/StephaneGrosLemesre/ExtensibleMath
>> >>
>> >> Or in the attached pdf.
>> >>
>> >> Please let me know what you think,
>> >> Kind regards,
>> >> Stéphane
>> >> --
>> >> Std-Proposals mailing list
>> >> Std-Proposals_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>