Date: Sun, 19 Jul 2026 15:56:40 +0200
On 7/19/26 14:00, Lorand Szollosi via Std-Proposals wrote:
> Now - cpass and uneval are relatively simple solutions that don’t need yet another spinoff language like Java, wasm, c—, Rust, AspectC++ etc. - all of which were (and could still be, to some extent) ideas based on C++ and most of those ideas could be backported as features, with the way proposed by myself, many of those (and many of the ‘good idea’ proposals) as *library* features. Neither of these change a bit in the grammar: these only specify what the code does.
The C++ specification is split into two parts: The core language
specification and a standard library on top of that.
The core language specifies the basics: how tokens are formed,
what they mean, and what the semantics of the resulting code is.
The standard library offers a set of classes and functions
(+ templates) within the framework of the core language.
Essentially, if a user could write the code (possibly with
resorting to assembly), then the standard library can offer
the facility. (Ignoring built-ins for type traits and reflection.)
A facility such as "uneval" that changes how the core language
interprets and evaluates tokens is not a library facility
(even though it might superficially satisfy the C++ grammar,
which is but one part of the core language), and needs to be
a core language facility. That's not a statement about the
value of the facility itself, it's just a statement on where
and how it needs to be specified.
And we do approve changes to the core language at every
WG21 meeting, so this is not an insurmountable hurdle.
> Btw, CppMusical Track 1
I don't know which music you're talking about, and why music would be
arranged in "tracks". This feels seriously off-topic for this venue.
> we don’t yet have authentication-authorisation-accounting/auditing (consent and risk) and information privacy primitives in STL, do we? Because can’t say that isn’t an EU expectation in data management - e.g., healthcare data in defense sector, consent to giving birth, health and couples’ private sharing vs. chidren’s rights, to name a few areas that can be efficiently addressed with such content filters [0].
It might be better not to use a single e-mail thread for vastly
different topics. If you wish to make a proposal in this area,
feel free to do so, but please make that a separate e-mail thread.
Jens
> Now - cpass and uneval are relatively simple solutions that don’t need yet another spinoff language like Java, wasm, c—, Rust, AspectC++ etc. - all of which were (and could still be, to some extent) ideas based on C++ and most of those ideas could be backported as features, with the way proposed by myself, many of those (and many of the ‘good idea’ proposals) as *library* features. Neither of these change a bit in the grammar: these only specify what the code does.
The C++ specification is split into two parts: The core language
specification and a standard library on top of that.
The core language specifies the basics: how tokens are formed,
what they mean, and what the semantics of the resulting code is.
The standard library offers a set of classes and functions
(+ templates) within the framework of the core language.
Essentially, if a user could write the code (possibly with
resorting to assembly), then the standard library can offer
the facility. (Ignoring built-ins for type traits and reflection.)
A facility such as "uneval" that changes how the core language
interprets and evaluates tokens is not a library facility
(even though it might superficially satisfy the C++ grammar,
which is but one part of the core language), and needs to be
a core language facility. That's not a statement about the
value of the facility itself, it's just a statement on where
and how it needs to be specified.
And we do approve changes to the core language at every
WG21 meeting, so this is not an insurmountable hurdle.
> Btw, CppMusical Track 1
I don't know which music you're talking about, and why music would be
arranged in "tracks". This feels seriously off-topic for this venue.
> we don’t yet have authentication-authorisation-accounting/auditing (consent and risk) and information privacy primitives in STL, do we? Because can’t say that isn’t an EU expectation in data management - e.g., healthcare data in defense sector, consent to giving birth, health and couples’ private sharing vs. chidren’s rights, to name a few areas that can be efficiently addressed with such content filters [0].
It might be better not to use a single e-mail thread for vastly
different topics. If you wish to make a proposal in this area,
feel free to do so, but please make that a separate e-mail thread.
Jens
Received on 2026-07-19 13:56:47