pon., 13 maj 2024 o 11:06 Giuseppe D'Angelo via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hi,
>
> Il 13/05/24 09:45, Ahmed Elbadawy via Std-Proposals ha scritto:
> > Currently, using |std::any| requires explicit casting using
> > |std::any_cast |but adding a conversion function to |std::any| will
> > allow users to convert the stored value to a specified type directly,
> > without the need for |std::any_cast| which will
> >
> > 1. Improve Readability: The proposed conversion function makes code
> > more readable by eliminating the need for explicit casts.
>
> You need to bring more data to this discussion. Why are explicit casts
> "bad"? Why do they hinder readability? Why does C.164 say to avoid
> implicit casts?
>
>
>
> > 2. Simplified Usage: Developers can use the conversion function
> > directly, reducing the complexity of working with |std::any|.
>
> Ditto.
>
>
> > Considering the scenario where |std::any|is used as an argument to an
> > overloaded function.
>
> Why does the function need to be overloaded? What's in the overload set?
>
>
> > With the proposed conversion function, we can use
> > the builtin *static_cast*which is more convenient to be used than the
> > template function *std::any_cast.*
>
> Once more, [citation needed].
>
> Are
>
> * static_cast<type>(foo)
> * std::any_cast<type>(foo)
>
> really *that* different?
>

I have one caveat, in generic code you need to know what type
you have there to choose the correct cast. This why I like
Herb `as` and `is` proposal as it warps all cast in one safe "api".
like:

```
type bar(auto foo)
{
    if (foo is type)
    {
        return foo as type;
    }
    return {};
}
```

And this will work in the majority of cases.

> Besides, you're proposing to even avoid the static_cast entirely because
> your conversion operator is *implicit*. Now you have an implicit
> conversion operator which may throw an exception, that sounds very bad
> to me.
>
>
> My 2 c,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals