At one time (within MISRA) we were discussing options for an expression attribute that would request "full" or "volatile" semantics for evaluation of an expression: not optimize out any reads or stores, and not assume any value ranges, even if none of the entities within the expression were originally declared with a `volatile` qualifier.

This was an evolution of the direction of Andrew's rejected proposal for a `defensive` attribute, which although not morally opposed to the idea, WG14 decided was not implementable as-described in N2258. `defensive` would have gone in a different position.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2258.htm

Maybe this is too strict to trust an ignorable attribute with, but from another perspective it does make sense to put in attribute-space as it _shouldn't_ affect the result of a correct program (but may be wanted to defensively enforce that it _is_ correct).

I guess this would be the exact opposite of an `unsequenced` expression attribute.

Thanks,

Alex

Perforce Software

Alex Celeste (she/her/elle) | Elder Witch of the C Compiler, Perforce QAC

Perforce Software    P +1 612.517.2100

Visit Us On: LinkedIn | YouTube



From: Liaison <liaison-bounces@lists.isocpp.org> on behalf of Jₑₙₛ Gustedt via Liaison <liaison@lists.isocpp.org>
Sent: 07 July 2026 07:53
To: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Cc: Jₑₙₛ Gustedt <jens.gustedt@inria.fr>; WG14/WG21 liaison mailing list <liaison@lists.isocpp.org>
Subject: Re: [isocpp-wg14/wg21-liaison] Attributes on expressions
 
Giuseppe,

on Mon, 6 Jul 2026 16:27:19 +0200 you (Giuseppe D'Angelo
<giuseppe.dangelo@kdab.com>) wrote:

> Hello,
>
> Il 05/07/26 10:54, Jₑₙₛ Gustedt ha scritto:
> > Hi,
> > apologies again that I will not be able to make it to the meeting.
> >
> > on Sun, 28 Jun 2026 10:25:22 +0200 you (Jan Schultke
> > <janschultke@googlemail.com>) wrote:
> >
> >>     - P3093R0
> >>     <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3093r0.html>
> >> Attributes
> >>     on expressions (Giuseppe D'Angelo)
> >
> > I like the paper and think that the chosen syntax is a good one.
> > That is definitively material that we should prospect putting into
> > C, too. (But we'd need implementations, first.)
> >
> > The paper seems to be incomplete, but maybe I overlooked an
> > explanation for this: I think there should also be wording that adds
> > this new possibility to some standard attributes. For C come to mind
> > all standard attributes with the exeption of `[[fallthrough]]`, but
> > C++ has probably more attributes that would be interesting on
> > expressions.
> >
> > I get it, that some of these standard attributes would need
> > discussion in a separate paper to clarify the semantics, but others
> > should be quite direct.
>
> Thank you for your feedback.
>
> To clarify a bit around the context, I did have a separate proposal
> (P2992, attribute [[discard("reason")]]) which was meant to be an
> attribute on expressions (and on statements). Unfortunately it didn't
> pass EWG, so now I don't really have a poster-child attribute on
> expressions...
>
>
> Regarding the existing standard C++ attributes, I am not quite sure
> that any of them could meaningfully be applied to expressions; maybe
> just [[likely]]?
>
> For the others:
>
> * [[noreturn]] is for function declarations. Maybe one could
> entertain the idea that the evaluation of an expression never
> returns, but I'm not sure what it would mean.

It would mean for example, that the application knows that with a
particular choice of parameters a certain function call can never
return. That could be a precious optimization hint.

> (It could also be
> emulated today by applying [[noreturn]] to an IILE.)

what is IILE?

> * [[deprected]] is for declarations, not statements in general and
> not expressions. What what would it mean that an expression is
> "deprecated"?

In general, a deprecated feature (e.g function) can use other
deprecated features without triggering additional
diagnostics. `[[deprecated]]` on an expression could mean that, don't
diagnose other deprecated features that it uses. (But that would
probably merit a different name.)

> * [[fallthrough]] is for null statements only, doesn't make sense for
> an expression;
>
> * [[maybe_unused]] is for "entity declarations" at large, doesn't
> make sense for an expression;

both agreed

> * [[nodiscard]] is for functions and enum/class declarations. I don't
> get why one would write [[nodiscard]] for an expression -- just use
> the result if you don't want it to be discarded?

That would be useful for macros that evaluate to expressions.
In general, most function attributes probably make sense when put on
expressions in macros.

> * [[no_unique_address]] is for NSDMs, doesn't make sense for an
> expression;
>
> * [[assume(expr)]] is deliberately NOT on an expression one assumes,
> since that expression is meant to be unevaluated;
>
> * [[indeterminate]] is only for automatic variables, doesn't make
> sense for an expression.

I wouldn't know about these, my C++ expertise goes not far enough for
that.

In C, in addition we have `[[unsequenced]]` and `[[reproducible]]`
where the basic properties are actually defined as properties of
evaluations. These are then plugged onto function types by requesting
that every call to the function has the corresponding property. So
here it would make perfect sense to be able to put such an attribute
on an expression.


Thanks
Jₑₙₛ

--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA antenne de Strasbourg :::::::::::::::::: Camus ::
:: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2026/07/1669.php


CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.

This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.