Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

comp.lang.c++@googlegroups.com

Google Groups

Topic digest
View all topics

• Std::any vs std::optional - 2 Updates

Std::any vs std::optional

woodbrian77@gmail.com: May 25 05:21PM -0700 > Hi everyone and thanks Brian for bringing this to my attention.   > Clearly the time-honored notion of "a value or the absence thereof" has many good uses, many of which distinct from "a value of any type whatsoever" or "a value of a known set of types". So nothing wrong with having and using each of the above where applicable.   I agree as far as optional and variant. Perhaps there are some good uses for std::any, but I haven't seen them yet.     > My remark about std::optional has to do with it having introduced (for the first time in std) the pointer syntax for a non-pointer value. That is questionable in and of itself - are we really after more undefined behavior in standard library APIs? -, but the worst of it is it has created a precedent - now new loosely-related artifacts (such as of course std::expected) need to integrate the pointer syntax as well, or carefully justify not doing so.   I hadn't thought about the precedent part.     Brian

"Öö Tiib" <ootiib@hot.ee>: May 26 01:34PM -0700 > precedent - now new loosely-related artifacts (such as of course > std::expected) need to integrate the pointer syntax as well, or > carefully justify not doing so.   The problem is precedent of making the syntax of value and pointer usage to overlap? In practice the syntax already overlaps in C++. The references and function pointers hide that they are pointers, now something pretends being pointer. Are there some deeper problems? I do not understand what you mean with undefined behaviors.   The optional is useful in places where absence of value and nullability are needed. That can be for other reasons but errors. In such places usual alternative is (way differently performing) unique_ptr. If unique_ptr or optional is more optimal can be even hard to tell without profiling. So the pointer-like operators are likely meant to simplify refactoring and generalizing over those alternatives.   It can be that same syntax is not good interface for "expected" value/error union. Some languages use enum syntax for declaring and switch-case for working with tagged unions. I don't know how to achieve that with C++.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.