CETL's cetl::any

[serges147]

Fix for issue #83

[pavel-kirienko]

@thirtytwobits this is waiting for review. The Sonar failure is due to the coverage check which we discussed at the call.

[thirtytwobits]

move utility.hpp include inside of the #ifndef CETL_H_ERASE section below

[serges147]

@thirtytwobits With my recent renaming (any → unbounded_variant) AND removing all related PF-any-stuff, is this comment (and 2 below) are still applicable? I'm asking b/c I'm not sure what needs to be done...

[thirtytwobits]

illegal dependency: CETL pf can use CETL first-class but not the other way around.

[thirtytwobits]

move within CETL_H_ERASE

[thirtytwobits]

just omit this header for now. It's completely off the mark. What we actually want is to have something like this in the cetlpf.hpp

using bad_any_cast = std::bad_any_cast;

template <typename T> constexpr bool is_rtti_convertible = std::false_type::value;
using type_id = std::type_info;

// Forward declarations
template <std::size_t Footprint, bool Copyable, bool Movable, std::size_t Alignment> class any;

template <typename T> inline constexpr const type_id &type_id_value()
{
    return typeid(T);
}

template <typename T> using in_place_type_t = std::in_place_type_t<T>;

template <typename T> inline constexpr std::in_place_type_t<T> in_place_type;

template <std::size_t I> using in_place_index_t = std::in_place_index_t<I>;

template <std::size_t I> inline constexpr std::in_place_index_t<I> in_place_index;

// Forward declarations
template <std::size_t Footprint, bool Copyable, bool Movable, std::size_t Alignment> class any;

[pavel-kirienko]

This is easy to change but I want to confirm a few things.

1. I think we originally discussed that the reliance on the native RTTI is not permitted, but now we're making it optional, configurable at build time, such that it conditionally replaces our cetl_rtti.

2. Our any is not a drop-in replacement for std::any (unlike, say, variant or span), so introducing it into the polyfill header as-is seems questionable. The original intention was to introduce a particular instantiation of our any into the polyfill namespace, that instantiation being a better approximation of std::any. Alternatively, we can avoid polyfilling std::any completely considering the differences. Substituting our any template for std::any is unlikely to be what we want.

[thirtytwobits]

With a few tweaks we leave open the possibility that our implementation can be redefined to use RTTI. This seems worth the minor effort to maintain. As for inclusion in the polyfill, let's just leave that for a later time.

[pavel-kirienko]

Understood.

[serges147]

No more such header.

[thirtytwobits]

We should refuse to generate any_cast for non-pointer types when exceptions are disabled. This is the approach we took with variable_length_array.hpp

[pavel-kirienko]

I'm expecting that in user code it will result in this:

T& val = any_cast<T>(my_any);

Being replaced with this:

T* const val = any_cast<T*>(&my_any);
assert(val != nullptr);

Where there is a robust assumption that the any contains T. One example would be the DynamicBuffer in LibCyphal.

Is it done to uphold compliance with a coding standard or there is other rationale?

[thirtytwobits]

Of my two rules for API design:

1. Make the API easy to use correctly
2. Make the API hard to use incorrectly

rule 2 applies here.

[pavel-kirienko]

Okay. But for the record we have throwing overloads in cetl::variant, like cetl::get.

[serges147]

I renamed any_cast to two functions:

• → get for value-returning; throws cetl::bad_unbounding_variant_access in case of failure
• → get_if for pointer-returning; returns nullptr in case of failure
  So now, this api is close to usual (type-bound) cetl::variant.

[thirtytwobits]

We need to change type_id_value to be functional to allow for typeid's required runtime. That is, the token must be replaceable with typeid when CETL RTTI is erased. Here's an example polyfill:

template <typename T> inline constexpr const type_id &type_id_value()
{
    return typeid(T);
}

This would require the token to look like type_id_value<Tp>() so we can invoke typeid.

[serges147]

@thirtytwobits Scott, is it possible that we handle this request as a separate issue? I'm asking b/c I currently don't understand requirements, as well as the exact way to reproduce it.

[pavel-kirienko]

@serges147 this is simply about replacing this:

template <typename TypeIDType>
constexpr type_id type_id_type_value = detail::type_id_type_value_impl(TypeIDType{});

with this:

template <typename TypeIDType>
constexpr type_id type_id_type_value() noexcept
{
    return detail::type_id_type_value_impl(TypeIDType{});
}

We must return by value because constexpr functions do not allow static storage duration locals. Alternatively, we keep the original type_id_type_value under a different name (perhaps move it into detail) and return a reference to it:

template <typename TypeIDType>
constexpr const type_id& type_id_type_value() noexcept
{
    return detail::type_id_type_value<TypeIDType>;
}

[serges147]

ok, I did the replacement. unfortunately, I still don't understand what exactly was the problem (and how to reproduce it, f.e. in unit tests), but I did as you proposed

[thirtytwobits]

This is misleading. Let's rename the header and type to static_any to avoid any confusion that this is a different implementation then the standard requires.

[pavel-kirienko]

static may not be a good choice if we extend this any with PMR support which we discussed in the past. Perhaps the following are better options:

• any2
• configurable_any
• heapless_any (works for PMR as well because we don't use the global heap directly)

[thirtytwobits]

• super_mega_any
• this_any_sponsored_by_progressive__progressive_will_save_you_hundreds_on_car_insurance
• less_evil_any

serious ones

many - sorta cheeky

any_of - what if we changed the template to take a variadic list of types and it does the max(sizeof(...)) so the usage would look like any_of<int, float, double> a{1};?

[pavel-kirienko]

ok here's another inspired by your comment:

• unbounded_variant

what if we changed the template to take a variadic list of types and it does the max(sizeof(...)) so the usage would look like any_of<int, float, double> a{1};?

If you need variant, you know where to find it. Perhaps you want an overload for make_any; we could add that later.

[thirtytwobits]

unbounded_variant. love it

[serges147]

cetl::unbounded_variant it is; no PF stuff anymore.

[sonarqubecloud]

Quality Gate failed

Failed conditions
61.9% Coverage on New Code (required ≥ 90%)

See analysis details on SonarCloud