C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Function-bound objects with unary operator %

From: Adrian Johnston <ajohnston4536_at_[hidden]>
Date: Mon, 1 Jun 2026 20:53:03 -0700
I agree there should be a REALLY strong motivation before overloading any
more punctuation. Teachability is a concern for me too.

And dynamic stack allocation has encountered resistance in the past. This
particular case doesn't look that bad to me, but it is going against the
prevailing winds.


On Mon, Jun 1, 2026 at 7:41 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Monday, 1 June 2026 14:41:15 Pacific Daylight Time Frederick Virchanza
> Gotham via Std-Proposals wrote:
> > Well the unary operator '%' is programmed to become "classalloca( )",
> > so you can write "classalloca( std::async( EntryPoint ) )" instead of
> > "%std::async(EntryPoint)".
> >
> > I think the unary operator is cool for this though. Like how
> > structured bindings didn't add any functionality at all to the
> > language but were just deemed cool enough to make it in.
>
> There is only one symbolic operator added to C++ since its inception, and
> that's the spaceship one. Even compared to C, the only symbolic
> differences are
> the scope operator (which is not really an operator since at least the
> left
> side can't be a variable) and the two pointer-to-member accessors .* and
> ->*.
>
> Adding unary % needs to have REALLY strong motivation and a good analysis
> of
> whether it may fall afoul of existing syntax. So think about whether it's
> really required or is just a nifty thing you came up with. How often is it
> going to be used? Is it worth modifying the language syntax for it? How
> teachable is it? Would it make more sense to spell out (imagine if we had
> used
> unary % to mean "alignof")?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2026-06-02 03:53:20