On 8/21/26 7:56 AM, Arsen Arsenović wrote:
Here's a version with those changes made. (I'm yet to remove Syd's
expected/optional)
It looks like nothing in this patch seems to use the merge/join
functions that rely on tl::expected, so maybe we could defer those
functions for now?
But, I've just realized something that may be a slight issue (but maybe
it's immaterial): the union between two instances of cv_qualifier is not
always necessarily a total function either.
For what is called 'join' on qualifier sets, i.e. a syntactic union, it
is a complete function (unlike for qualifier sets), and coincides with
the bit-OR operator fine.
But, for what's called 'merge' on qualifier sets, i.e. creating a
new qualifier set such that it is compatible with both input qualifier
sets, it is not:
~$ gcc -x c - -fsyntax-only <<<'void foo(_Atomic int *x, int *y) { 1/(y ? x
: y); }'
<stdin>: In function ‘foo’:
<stdin>:1:45: error: pointer type mismatch in conditional expression
[-Wincompatible-pointer-types]
<stdin>:1:43: note: first expression has type ‘_Atomic int *’
<stdin>:1:47: note: second expression has type ‘int *’
I say this may be immaterial because C++ (and other non-C languages) do
not have _Atomic qualification at all, so it is a total function in
those, and C would (ideally, eventually) use qualifier_set directly
always.
This could be addressed by deleting operator| on cv_qualifier and
providing cv_merge/cv_join perhaps, but given the above I'm not sure
it's worth it.
Yeah, I think it's fine; if the result of | isn't usable, we should get
a suitable diagnostic.
Jason
