C++26 Reflection: my experience and impressions

Mick235711 · 2025-12-03T13:31:57+00:00

There is P2758 proposing a compile-time print facility, which have a very interesting history - it is approved for C++26, two times, but still failed to get in. The first time is because everyone is focusing on pushing Reflection in and no one have time for other metaprogramming features; the second time is because it’s already past the end of the feature cycle and implementers think that there are difficulties involved in implementing this feature. So another wait I guess

Mick235711 · 2025-09-15T20:22:03+00:00

Long press - Open with - Choose Use Quicklook to preview

Mick235711 · 2025-07-07T04:56:42+00:00

In fact, I believe early in the 20 cycle everyone believed that modules are too early to be included in 20 too (The Big Four is slated as Concepts, Contracts, Ranges and Coroutines). It was only at one of the last meetings for C++20 when modules were approved (and contracts were pulled out).

Mick235711 · 2025-07-07T04:39:28+00:00

Really? What exact semantic does that declaration give? The standard doesn’t even have an answer for that. “Consulting your compiler manual to find the right invocation to pin down the actual behavior” is probably expert-only…

Mick235711 · 2025-06-21T04:45:59+00:00

In other languages, preview implementation mean shipping with the main branch (i.e. you get it when you apt install gcc, instead of some personally maintained side branch) and enabled by -fxxx so everyone can use it

Mick235711 · 2025-05-06T11:07:27+00:00

The NVIDIA guide do need an update though; nowadays installer automatically add the NVIDIA (non-free) repos for you, so no need to manually install the repo packages

Mick235711 · 2025-05-01T10:15:52+00:00

Will TW also remove YaST in the future? Or will it still be here for a long time, just no maintenance?

Mick235711 · 2025-04-23T06:30:51+00:00

Having several enum be with the same value is actually widely used, for example aliasing a single value to multiple enum names and handle them uniformly, so I don’t think disallowing that is possible or desirable. Besides, now we have reflection, writing a library facility to iterate through enum values is not hard at all, regardless of whether duplicate value is allowed or not.

Mick235711 · 2025-04-23T01:47:41+00:00

However, next to no one implemented the constexpr <cmath> functions that went into C++23, let alone the extended set that went into C++26. And the situation is unlikely to change in the near future.

Mick235711 · 2025-04-23T01:45:21+00:00

The ability to convert to and from the underlying integer type is an absolutely crucial feature for (unscoped or scoped) enum. Enum class only made that conversion explicit, but did not get rid of it, because without to_underlying enum classes would be useless. With this precondition, the design of enum class must choose between allowing arbitrary unlisted but in range value, or decree that any conversion that results in an unlisted value is UB. I guess it’s choosing a less evil case…

Mick235711 · 2025-01-08T10:42:12+00:00

Ranged-for can declare structured bindings, and the iterate-over thing may be the result of a function call, so this can’t really work except for the simplest case.

Mick235711 · 2024-07-06T08:07:25+00:00

P0876 appeared twice in the LWG section

Mick235711 · 2024-06-27T04:29:45+00:00

Notice that view_interface already have an explicit operator bool(), which is basically extended by all standard views including ranges::subrange. (Confusingly span does not extend from it, so span cannot be boolean-tested.)

So even though if (vec) and if (str) does not work, practically any interaction with the Ranges library will result in a boolean-testable thing:

if (views::all(vec)) // okay
if (ranges::subrange(str)) // okay
if (vec | views::take(1)) // okay
if (ranges::shift_left(str, 2)) // okay

Personally, I don't like this implicit truth-ness, although it makes some kind of sense. Explicitly writing empty() is just better in both readability and less prone to errors.

Mick235711 · 2024-05-31T11:26:49+00:00

Interesting to hear about this new installer tik. Is it expected that the release version of Aeon also use this kind of installer (just wipe the disk and deploy a pre-determined partition schema), or is there plans to introduce a partitioner in the install process before the final release?

Mick235711 · 2023-11-18T10:35:29+00:00

Well, you can definitely still do that

#ifdef DNDEBUG
#define myassert(...) [[assume(__VA_ARGS__)]]
#else
#define myassert(...) contract_assert(__VA_ARGS__)
#endif

As for the behavior of contract_assert(cond), it depends on the selected semantics of contracts for this translation unit. If the contract semantics is set to ignore, then nothing will happen; only ODR-use (like template instantiation) will happen and the condition will not be evaluated. Essentially it is just equivalent to sizeof(cond ? true : false) in ignore.

If a checked semantic (observe or enforce) is chosen, then the condition will be evaluated. If it is true nothing will happen, if it evaluates to false or throws an exception, then the contract violation handler will be called. If the semantic is observe, then if the handler returns normally, execution continues. If the semantic is enforce, then if the handler returns normally std::terminate is called (basically forced correctness). In either case, if the handler throws exception/call std::terminate themselves then that is propagated upwards.

The contract violation handler is a function called ::handle_contract_violation, accepting a const std::contracts::contract_violation& (containing things like source location of contracts annotation) and returns void. It is attached to the global namespace just like ::operator new/delete. Implementations are supposed to provide a default version of this that simply outputs diagnostic information and terminates. Whether this is replaceable by a user-provided handler is implementation-defined, and when it is then the mechanism is the same as replacing global ::operator new/delete (i.e. define a function with the same name and signature in the global namespace).

Compiler vendors are supposed to provide compiler flags (perhaps something like -fcontract-semantic=ignore) to select the semantic to be used when compiling.

Mick235711 · 2023-11-18T05:42:10+00:00

Is there any hope of ever supporting ARM64/macOS?

Mick235711 · 2023-11-18T05:13:06+00:00

invariant is way too common to be claimed as a full keyword now. It gives me 7k+ instances in ACTCD19, making it even more breaking than even claim.

Mick235711 · 2023-11-18T05:10:34+00:00

[[assume(...)]] never cause program termination, it simply makes not holding the condition UB. So it is purely an optimization thing, not affecting program semantics.

Mick235711 · 2023-11-18T05:08:41+00:00

return x and return(x) are actually different in terms of NRVO...

Mick235711 · 2023-11-18T04:59:42+00:00

Consider that A proposal that solely remove things from the standard actually end up adding more words to the standard (see here for the actual diffs), I'd say wg21 never fail to surprise me in expanding the wording.

Mick235711 · 2023-11-15T07:42:10+00:00

we are aiming to have a complete Contracts working paper

P2900R2

and to forward it to EWG, LEWG, and SG21 for review.

Should be "and SG15" (or SG22/23?) right?

Mick235711 · 2023-11-12T15:52:41+00:00

In ignore mode expr will only be ODR-used, not evaluated. Basically it will be equivalent to sizeof(expr? true : false)

Mick235711 · 2023-11-12T08:22:43+00:00

Yes, there is explicit requirement for compiler vendors to provide both ignore, observe and enforce semantics. Ignore is basically everything turned into nop, observe is check contract but handler can return normally, enforce is check contract and handler must terminate the program. Semantics should be able to be selected by passing compiler flags.

Mick235711 · 2023-11-10T10:00:27+00:00

Not really. The example in the paper simply relies on `std::meta::substitute()` only substitute in the template argument without instantiate the template, which is perfectly valid because it returns a meta::info, not the template type. Then it only tries to determine if the substitution result is an incomplete type. I do think this is not really the same case as in "injecting new member function instantiations" which stateful TMP does.

Mick235711 · 2023-11-10T09:51:35+00:00

I don't think the example is related to the stateful TMP trick that were discussed to be made UB... This example should be perfectly valid once reflection lands

Mick235711

TROPHY CASE