220 38116 article Path: news.gmane.org!.POSTED!not-for-mail From: tortoise741@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Convert a variant into an optional? Date: Thu, 17 May 2018 03:30:12 -0700 (PDT) Lines: 301 Approved: news@gmane.org Message-ID: References: <1c089cc9-4f8a-4778-b92b-2d3b95b211e1@isocpp.org> <2e6b1fb6-e7e1-fc87-bb42-b5179e826638@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_815_1324439873.1526553012730" X-Trace: blaine.gmane.org 1526552889 14204 195.159.176.226 (17 May 2018 10:28:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 May 2018 10:28:09 +0000 (UTC) Cc: tortoise741@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDJ35HPXFAILLM7V24CRUBBYXGJKY@isocpp.org Thu May 17 12:28:05 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fJG8h-0003YK-Vq for gclcip-std-proposals@m.gmane.org; Thu, 17 May 2018 12:28:04 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id w84-v6sf3445087vkw.2 for ; Thu, 17 May 2018 03:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=fB0E5fIYISairj8hRnnXzVnumzdR1LGt5EwabW/XGjo=; b=S4iKViknQzXlN3ZS/vVWzL7M6O/W2ox9Wh/jKb+VLpmt+q609sjxq3Nhp6ysR9EYn5 6rXuLNrbYWE2Im/gQb+PzOZdQXSyVivkgblBdlZs7xNb6ddDsvU2/X9reBK4/aZJ1sPw YOEGXTKsR5/6s7s0d0B4lHxNrZx+NFriaE7BKeLOSRbwOdcE3BM4zeOQfMrg560rzyqA Y/ZXHJpP7LdUcTz7g5cWXfU6Fl6v6FIe3W6WCOhq2uiDc5FdTblBTfCnwdDiJ8T4UYy/ ByfW78mZJMPOLhp56s1xaTUqeeaRb76px//cUUMA/d90GTlU1g00Ylmk8QBBIzjwNOhM XV8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=fB0E5fIYISairj8hRnnXzVnumzdR1LGt5EwabW/XGjo=; b=XFZDlBG3CqAnRHlxkX/yiuYmbi7Swzx2Sq8CO82fkvou42LP9mpsQVGf6OkmowlTy0 0svvL47397YFmRQ0A3QPPZp9MVO+i/IYFlZK4cpIQjQUI4wYLkIedtZBNhghTdZ8vPBn rcVOuTjWftPQstPjnb/vMl2jDuBOW7mcVmZyPHIizA5XJMujlhwSHuCu0oEOMp09Ho58 2b3nFN1CzlWTpvmkOvmzT4FPvlronzwQHE+v5kfSJTs/F4KLQ+sNTC8var1Hna+N6ST3 2f44CuU55G2jBkS8G0jd7hx4uMaHtXHWl1mgLHKm40of2QQmv3xOw6B2AirmaeAX7eHm oxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=fB0E5fIYISairj8hRnnXzVnumzdR1LGt5EwabW/XGjo=; b=gzUKkY5AgM3nZJJ6uG8lqYRYfpYrxxDgZwOlE0g6pRqMZ1w5jdXdwIx27XHwmV+s0T WhMFsphjhDq1r4qrtbqgmG4IuLTkLAi908a6qooUprGMT1CmVRlI5E+DMn07VwZc2OcC nx47e/2s63NHRHmk77JZiq1mafSG5E2WmaZ3hvK1uhEQU048BcQ8/2I7/eU4S8TwwPSK 1Yuq4eCfKbHAGwNNNxsKOgpUNXuXbyvoD08MkBHeZRk2bBTBeLOPwcPYLN61/Nj++0Tk Q4lbz4spfzSX4dFXuc1hS09N5x1JKjRsNdwjW6MGdOqGSgnOKojS6gD1xkZ3zNy/vvZr SQzQ== X-Gm-Message-State: ALKqPwfxsBZcdOibrAIpclXLUEbZCYWeQQc86fKKb4ndweUh75QjrFnx +VqOqVN49RuyrhUU/9CUM1Bcqw== X-Google-Smtp-Source: AB8JxZrmVwHubeDgsYsUkvn3ZKhEDWfpGdwVRv2M2ahX+MID0Y1B9hdQQpuq7aKQRLqSA9WJWSStKg== X-Received: by 2002:ab0:4c20:: with SMTP id l32-v6mr3095590uaf.45.1526553014336; Thu, 17 May 2018 03:30:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1f:3f50:: with SMTP id m77-v6ls2981996vka.3.gmail; Thu, 17 May 2018 03:30:13 -0700 (PDT) X-Received: by 2002:a1f:951:: with SMTP id 78-v6mr638388vkj.0.1526553013274; Thu, 17 May 2018 03:30:13 -0700 (PDT) In-Reply-To: <2e6b1fb6-e7e1-fc87-bb42-b5179e826638@wanadoo.fr> X-Original-Sender: tortoise741@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:38116 Archived-At: ------=_Part_815_1324439873.1526553012730 Content-Type: multipart/alternative; boundary="----=_Part_816_571158546.1526553012731" ------=_Part_816_571158546.1526553012731 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, 15 May 2018 22:34:36 UTC+1, Vicente J. Botet Escriba wrote: > > Le 15/05/2018 =C3=A0 17:39, torto...@gmail.com a =C3=A9crit= :=20 > > Hi,=20 > > Apologies if this has been asked before. variant and optional are= =20 > > quite common search terms.=20 > >=20 > > I'm wondering if there is, or should be a standard way to convert= =20 > > a variant into an optional?=20 > > Or if its a bad idea why there shouldn't be.=20 > >=20 > > Consider the following example. Imagine Foo is an object representing= =20 > > a configuration.=20 > > One part of the configuration bar has two possible modes of operation= =20 > > one requires one piece of configuration=20 > > and one requires the other but it is not valid to specify both.=20 > >=20 > > #include =20 > > #include =20 > >=20 > > class Foo=20 > > {=20 > > private:=20 > > std::variant bar;=20 > > public:=20 > > Foo(int a): bar(a) {}=20 > > Foo(const std::string& b): bar(b) {}=20 > >=20 > > std::optional getInt() const=20 > > {=20 > > std::optional ret;=20 > > auto got =3D std::get_if(&this->bar);=20 > > if (got) ret =3D *got;=20 > > return ret;=20 > > }=20 > >=20 > > std::optional getString() const=20 > > {=20 > > std::optional ret;=20 > > auto got =3D std::get_if(&this->bar);=20 > > if (got) ret =3D *got;=20 > > return ret;=20 > > }=20 > > };=20 > >=20 > > There seems to be a lot of boilerplate to convert the variant into a=20 > > optional for the return.=20 > > There is an inefficiency here in that the type contained has to be=20 > > checked twice to use this.=20 > >=20 > > There are other ways to do this. You can expose the variant member and= =20 > > use a visitor=20 > > but using a visitor feels like overkill for this. Also the variant is= =20 > > an internal implementation detail.=20 > > An equally valid implementation would have two different optional=20 > > members (but would not enforce their mutual exclusivity).=20 > >=20 > > So do we need (or is there already) something kind of like:=20 > >=20 > > std::optional getString() const=20 > > {=20 > > return make_optional(this->bar);=20 > > }=20 > >=20 > > or bikeshedding:=20 > >=20 > > std::optional getString() const=20 > > {=20 > > return to_optional(this->bar);=20 > > }=20 > >=20 > > The conversion is simple, but we don't need to do the conversion until=20 > requested. We can see a variant as some kind of ValueOrNone type= =20 > (that can not change of alternative) once we select one of the=20 > alternatives T. Lets name this function select(SumType).=20 > > The conversion would be done only when requested, e.g. by an implicit=20 > conversion.=20 > > optional o =3D select(SumType);=20 > > > However, we could as well=20 > > auto von =3D select(SumType);=20 > > von is not an optional. It is something else, a reference to a=20 > sum-type, with the perspective of only one of the alternatives. Now we=20 > can use von as a ValueOrNone, with the usual von.has_value() and *von.=20 > Note that these functions don't need to check the type twice:=20 > von.has_value() should be equivalent to std::get_if(&von) and=20 > *von equivalent to std::get(von).=20 > > > Just my 2cts.=20 > > Vicente=20 > > I very much like the name select. I see your argument that a ValueOrNone isn't strictly an optional but if it= =20 isn't don't we complicate the language with yet another "maybe" type? Wouldn't the language be cleaner with just= =20 one? I guess the answer is adding optional references as previously mentioned? Regards, Bruce. =20 --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/bbbc65c3-b9e5-4365-9d06-591fcd86d93a%40isocpp.or= g. ------=_Part_816_571158546.1526553012731 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, 15 May 2018 22:34:36 UTC+1, Vicente J. Botet E= scriba wrote:
Le 15/05/2018 = =C3=A0 17:39, torto...@gmail.com a =C3=A9crit=C2=A0:
> Hi,
> =C2=A0=C2=A0=C2=A0 Apologies if this has been asked before. varian= t and optional are=20
> quite common search terms.
>
> =C2=A0=C2=A0=C2=A0 I'm wondering if there is, or should be a s= tandard way to convert=20
> a variant into an optional?
> Or if its a bad idea why there shouldn't be.
>
> Consider the following example. Imagine Foo is an object represent= ing=20
> a configuration.
> One part of the configuration bar has two possible modes of operat= ion=20
> one requires one piece of configuration
> and one requires the other but it is not valid to specify both.
>
> #include <variant>
> #include <optional>
>
> class Foo
> {
> private:
> =C2=A0=C2=A0=C2=A0 std::variant<int, std::string> bar;
> public:
> =C2=A0=C2=A0=C2=A0 Foo(int a): bar(a) {}
> =C2=A0=C2=A0=C2=A0 Foo(const std::string& b): bar(b) {}
>
> =C2=A0=C2=A0=C2=A0 std::optional<int> getInt() const
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::optional<int>= ; ret;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto got =3D std::get_i= f<int>(&this->bar);
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (got) ret =3D *got;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return ret;
> =C2=A0=C2=A0=C2=A0 }
>
> =C2=A0=C2=A0=C2=A0 std::optional<std::string> getString() co= nst
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::optional<std::s= tring> ret;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto got =3D std::get_i= f<std::string>(&this->bar);
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (got) ret =3D *got;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return ret;
> =C2=A0=C2=A0=C2=A0 }
> };
>
> There seems to be a lot of boilerplate to convert the variant into= a=20
> optional for the return.
> There is an inefficiency here in that the type contained has to be= =20
> checked twice to use this.
>
> There are other ways to do this. You can expose the variant member= and=20
> use a visitor
> but using a visitor feels like overkill for this. Also the variant= is=20
> an internal implementation detail.
> An equally valid implementation would have two different optional= =20
> members (but would not enforce their mutual exclusivity).
>
> So do we need (or is there already) something kind of like:
>
> =C2=A0=C2=A0=C2=A0 std::optional<std::string> getString() co= nst
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return make_optional<= ;std::string>(this->bar);
> =C2=A0=C2=A0=C2=A0 }
>
> or bikeshedding:
>
> =C2=A0=C2=A0=C2=A0 std::optional<std::string> getString() co= nst
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return to_optional<s= td::string>(this->bar);
> =C2=A0=C2=A0=C2=A0 }
>

The conversion is simple, but we don't need to do the conversion un= til=20
requested. We can see a variant<Ts...> as some kind of ValueOrNon= e type=20
(that can not change of alternative) once we select one of the=20
alternatives T. Lets name this function select<T>(SumType).

The conversion would be done only when requested, e.g. by an implicit= =20
conversion.

=C2=A0=C2=A0=C2=A0=C2=A0 optional<T> o =3D select<T>(SumTyp= e);


However, we could as well

=C2=A0=C2=A0=C2=A0=C2=A0 auto von =3D select<T>(SumType);

von is not an optional<T>. It is something else, a reference to a= =20
sum-type, with the perspective of only one of the alternatives. Now we= =20
can use von as a ValueOrNone, with the usual von.has_value() and *von.= =20
Note that these functions don't need to check the type twice:
=C2=A0=C2=A0=C2=A0=C2=A0 von.has_value() should be equivalent to std::g= et_if<T>(&von) and
=C2=A0=C2=A0=C2=A0=C2=A0 *von equivalent to std::get<T>(von).


Just my 2cts.

Vicente

I very much like the name select.

I see your a= rgument that a ValueOrNone isn't strictly an optional but if it isn'= ;t don't we complicate the language
with yet another "maybe&quo= t; type? Wouldn't the language be cleaner with just one?
I guess the= answer is adding optional references as previously mentioned?

Regar= ds,

Bruce.

=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/bbbc65c3-b9e5-4365-9d06-591fcd86d93a= %40isocpp.org.
------=_Part_816_571158546.1526553012731-- ------=_Part_815_1324439873.1526553012730-- .