Yes, std::remove_cvref_t combines the other two, in fact I believe it does so precisely (see the "Possible Implementation" on cppreference.com). The "...with a little extra" that I mention for std::decay_t in the article is that it does the same as std::remove_cvref_t plus some standardization of array and function types to pointer types (again, see the "Possible implementation" of it on cppreference.com). For my purposes it doesn't really matter which to use, and I mostly prefer std::decay_t for its brevity.

You might want to confirm that it is indeed zypper packages before you rearrange too much: Disk Usage Analysis on the desktop, or du -sch * on the console will get you some numbers by directory. It could also be cached packages, clean them up with zypper clean --all.

I'm not sure about specifying different destination directories with zypper, but you could try installing something like vscode from Flatpak rather than zypper, and specifying --user so it goes into your home directory (if that's a different partition).

I'd also look at your containers with podman and clean up any old ones, they can take up a lot of space.

Nice. I'd not thought of that one.

For the array type it can be useful to allow implicit copy to different arithmetic types (design choice, I'm now back to explicit constructors to disallow this for what it's worth). If allowed though, I still wanted a compile time check like this to ensure that it wasn't happening by accident in particular circumstances.

Yes, that's right, generic context, and you may be right on return value optimization. It was for implementing a collection of numerical functions that take array arguments, where the elements of those arrays could be of various arithmetic types, and the return type should be an array of a particular arithmetic type given promotion etc. The implementation was generic, and I was wanting to validate its correctness wrt return values having the correct arithmetic type without implicit copy.

That's a fair criticism around relying on implicit type conversion mechanics, and part of the tradeoff to make. On the other hand, I imagine (and my imagination may be limited) that one downside of static_assert is to increase verbosity, something like:

auto r = f();
static_assert(std::is_same_v<decltype(r),MyReturnType>> || !is_expensive_conversion_v<MyReturnType>);
return r;

Nice, good luck with it from here!

This would be better style in my opinion, but by way of correctness it seems the more fundamental issue is "return" missing in the if... else if... blocks.

Your get() function will always just return the value of the root node. I think you mean to have return get(value, ...) in each of its if statements.

I have Ubuntu 22.04 on a Dell XPS Plus 13 with OLED display. Looks great, battery life is good. Not sure how tuned the drivers are etc but definitely no need to avoid.

Welcome to C! Tiny suggestion to add to other comments: value is already Boolean, so there's no need to write if (value == 1), you can just write if (value). Similarly, following @chamaeleon@kbin.social's suggestion of using the ternary operator, you can write return value ? "Yes" : "No";.