Thiago, thanks. Good to hear Qt had the same naming debate and kept
"nonblocking".

Agreed on the definition. Clang's "doesn't lock" misses the blocking pipe
read — O(1) memory, still blocks. "Doesn't wait an unbounded time for a
resource" is what I want. I'll use that wording.

Bounded wait: once you cap it, you have two different guarantees. (1) It
never hangs forever. (2) It finishes within T — or returns incomplete, your
polling case. Those should be expressed separately, not as one overloaded
marker.

On (a)/(b)/(c): Arthur's CQual pointer sent me reading, and the takeaway I
land on is that open-ended, user-extensible qualifiers in the type system
are where the cost gets out of hand. But two or three baked-in effects are
too rigid to be worth the wrapper churn either. So my current leaning is to
split it:

   - (a) The type carries a closed, small set of effects. No user-defined
   qualifiers. That keeps the wrapper and specialization cost bounded.
   - (b) Those effects form a lattice: "takes no lock" implies "doesn't
   wait unboundedly". I think this is make-or-break — without implication
   everything gets marked twice. Your cancellation-point and vfork/execve
   cases seem to fall into the same hierarchy.
   - (c) Everything extensible or retrofitted goes through
   reflection-visible annotations outside the type. C++26 makes that workable,
   and it covers glibc headers you can't edit. (Arthur mentioned the same
   route in the other subthread.)

That's the shape I'm leaning toward: closed lattice in the type where
indirect-call soundness needs type identity, open annotation space outside
it for the rest. Whether the cut sits in the right place is what I'd want
stress-tested.

I'll work these into the paper and see how they hold up.

— Michael


>
>
> 1. Re: Float the idea: First-class effect.. (Thiago Macieira)
> ...
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 08 Jun 2026 16:36:58 -0700
> From: Thiago Macieira <thiago_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Float the idea: First-class effect..
> Message-ID: <HqTi_IxXRIKZBkEM4F3Zpw_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> On Monday, 8 June 2026 13:28:19 Pacific Daylight Time Michael Galuszka via
> Std-
> Proposals wrote:
> > My only reason for leaning toward keeping it is migration: Clang already
> > ships [[clang::nonblocking]] with exactly this meaning, and libc++ has
> > started annotating with it, so a divergent name would fork from a
> deployed,
> > in-use spelling. That's a real cost, but I don't think it's decisive, and
> > I'd genuinely rather land on a name people can live with than defend this
> > one.
>
> Yes, and when a macro was proposed for Qt for wrapping those, we had a
> discussion whether we wanted to find a different name that would be more
> specific, but ended up with just calling it "nonblocking".
>
> I think the definition from the Clang manual is insufficient. They only
> talk
> about locking resources (which malloc() in some implementations is), but
> in my
> opinion that should be about blocking while waiting for some resource for
> an
> arbitrary time. So, for example, if you try to read from a blocking pipe,
> even
> though the total memory consumption is O(1), it's still blocking.
>
> Now what happens if you put an upper limit on the wait? Since this appears
> to
> have been designed for real-time analysis (RTSan), I would conclude it
> isn't
> blocking because it will never block forever. But it might also not have
> concluded the work - that might be the case of polling on the pipe with a
> timeout before reading.
>
> > So ? does anyone have a spelling that says "signal-safe in the
> > [support.signal] sense, as a checked property of the function type"
>
> Those are so rare that TBH I've never thought they deserved markings. The
> cases that need this are by necessity very small functions and can be
> easily
> analysed by hand. BTW, there's an even more stringent category: safe
> between
> vfork() and execve().
>
> The way I see it, for this to be anything but niche for RTSan, it would
> need:
> a) to be extensible with arbitrary tags
> b) require a way to inform the analyser that a tag A implies B, so that we
> don't need every function marked both
> and possibly c) a way to annotate functions without modifying headers
>
> For example, another marker is "this a pthread cancellation point",
> because if
> cancellations are enabled and you call this function, your thread may die.
> Glibc has a marker for this: noexcept(false), because everything else is
> noexcept, and it uses the libunwind mechanism to cancel the thread and run
> cleanups. But no other libc has any marker, and it might be useful to do
> an
> analysis of cancellation-safety without having to modify the C library
> headers.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 870 bytes
> Desc: This is a digitally signed message part.
> URL: <
> https://lists.isocpp.org/std-proposals/attachments/20260608/db46d05f/attachment.sig
> >
>
> ********************************************
>