Date: Fri, 6 Nov 2020 10:11:09 -0500
On Thu, Nov 5, 2020 at 3:53 PM Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thu, Nov 5, 2020 at 12:09 PM Avi Kivity via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> How can the reader of *get_if() tell if the author intended this optimization, or was just lazy?
>
> Well, we know what semantics they intended — "get the value if possible; otherwise UB." Whether they get the optimization is up to the vendor (but vendors should make the performant choice, please).
>
>> Function names should communicate intent. "get_if()" communicates that you don't know if the variant holds the the type you are asking for or not.
>
> No it doesn't — I mean, not a priori. The identifier `get_if` is completely meaningless a priori — just like std::get and std::visit. The only way for a programmer to learn what these identifiers mean is to, well, learn. (I have a Back to Basics talk on algebraic data types I can recommend!) Once the programmer has learned the idioms around std::variant, they'll know what *std::get_if "communicates," by definition, because *std::get_if is one of the idioms around std::variant.
This solves all our naming problems. Let's just go with std::aaa001,
std::aaa002. People will learn the idioms.
*std::get_if is a bad idiom.
Someone suggested std::alternative, which is a decent name, although
it doesn't actually convey checking vs non-checking.
The other problem is that variant shouldn't have used std::get at all.
std::get, originally for tuple/pair, never throws - it is statically
known. It is a fundamentally different function than std::get on
variant. They shouldn't have the same name.
std::alternative should have been std::get for variants. (Or have
something like std::variant_get and std::tuple_get.)
>
> Of course, if the maintainer(s) of some particular codebase decide that they'd like another name for this operation, they can write a named function:
>
> Target uncheckedGetTarget(const std::variant<Target, Destination>& td) {
> MC_ASSERT(td.index() == 0);
> return *std::get_if<0>(&td);
> }
>
> I don't think the standard library ought to bother providing any "middle ground" between the existing C++17 idiom *std::get_if and the codebase-specific uncheckedGetTarget.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thu, Nov 5, 2020 at 12:09 PM Avi Kivity via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> How can the reader of *get_if() tell if the author intended this optimization, or was just lazy?
>
> Well, we know what semantics they intended — "get the value if possible; otherwise UB." Whether they get the optimization is up to the vendor (but vendors should make the performant choice, please).
>
>> Function names should communicate intent. "get_if()" communicates that you don't know if the variant holds the the type you are asking for or not.
>
> No it doesn't — I mean, not a priori. The identifier `get_if` is completely meaningless a priori — just like std::get and std::visit. The only way for a programmer to learn what these identifiers mean is to, well, learn. (I have a Back to Basics talk on algebraic data types I can recommend!) Once the programmer has learned the idioms around std::variant, they'll know what *std::get_if "communicates," by definition, because *std::get_if is one of the idioms around std::variant.
This solves all our naming problems. Let's just go with std::aaa001,
std::aaa002. People will learn the idioms.
*std::get_if is a bad idiom.
Someone suggested std::alternative, which is a decent name, although
it doesn't actually convey checking vs non-checking.
The other problem is that variant shouldn't have used std::get at all.
std::get, originally for tuple/pair, never throws - it is statically
known. It is a fundamentally different function than std::get on
variant. They shouldn't have the same name.
std::alternative should have been std::get for variants. (Or have
something like std::variant_get and std::tuple_get.)
>
> Of course, if the maintainer(s) of some particular codebase decide that they'd like another name for this operation, they can write a named function:
>
> Target uncheckedGetTarget(const std::variant<Target, Destination>& td) {
> MC_ASSERT(td.index() == 0);
> return *std::get_if<0>(&td);
> }
>
> I don't think the standard library ought to bother providing any "middle ground" between the existing C++17 idiom *std::get_if and the codebase-specific uncheckedGetTarget.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- Be seeing you, Tony
Received on 2020-11-06 09:11:25