this post was submitted on 24 Jun 2025
14 points (100.0% liked)
C++
2040 readers
2 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
because "if constexpr(...)" is a c++17 feature which i'm using it to allow usage of nl::unexpected() to return a nl::expected<nl::monostate, E> to nl::expected<T, E> in this copy constructor
but i could take a different approach and make 2 copy constructor one that explicitly takes
and another
I was also using "std::is_same_v" which is a c++17 feature instead "std::is_same<>::value" but i made a commit and changed it. it now compiles with c++14 but with c++17 extensions
That
if constexpr
in the case you mention does make the constructor clean as heck. Thanks for the clarification and the commits, by the way!ikr, constexpr is pretty cool. sure, no problem. I could make it fully compatible with c++14 without c++17 extensions if u wanna use it with c++14
I mean, I am not too concerned and it is your code. The
if constexpr
is just so much spiffier. You should do what's best for you.My own use case is that for pre-C++23 (and in particular, pre-C++20) workflows I'm looking to homogeneize the set of dependencies used to supplement the standard library and this looks like a great candidate lib. I already have my own
expected
, actually, but would rather someone else's who knows what they're doing. Since C++14 is the oldest standard I have to support directly for clients (big improvement: was C++03 before 2021) and it brought in the big changes that madeconstexpr
actually usable, I treat C++14 as a a sorta "C++ LTS" in my codebase.alright then.
I see.
expected
is such a great library to have regardless of the standard version. oh c++03, I'm not familiar with that standard.I enabled support for c++11 regardless, it's kinda cool to do so