220 38125 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Convert a variant into an optional? Date: Fri, 18 May 2018 14:21:08 +0200 Lines: 344 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/alternative; boundary="------------FEEA91565658746D77502380" X-Trace: blaine.gmane.org 1526645950 28535 195.159.176.226 (18 May 2018 12:19:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 May 2018 12:19:10 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 To: std-proposals@isocpp.org, tortoise741@gmail.com Original-X-From: std-proposals+bncBDH67CONY4PBBN4K7PLQKGQEGWRLPDQ@isocpp.org Fri May 18 14:19:06 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f197.google.com ([209.85.128.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fJeLd-0007Ad-0B for gclcip-std-proposals@m.gmane.org; Fri, 18 May 2018 14:19:01 +0200 Original-Received: by mail-wr0-f197.google.com with SMTP id p1-v6sf5283769wrm.7 for ; Fri, 18 May 2018 05:21:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1526646072; cv=pass; d=google.com; s=arc-20160816; b=eTyYUwZZallWAuKJOPbY2JZpV3K/ulLa7bYkij8oFH9/2stmcEIB/tt/A+Lqu+pD7H SazGtywSDIsWrTbX50lAPaxtGZ+bh0HzkjgX2W/mY8SHDhr/wYh50C85EZxUJHm8IOUI aWXMM7O263VfgBcRFX6z7KJB4eBFfrpWDYblSBgG0x3zEY/loorEwlbOHMsCj8ShD1kb KVD4XNUwsIcjP+zfdTe0uZ3sTokf/c/Tmu5awwfhfUzhUhti9Wx0rn8nt9KFY81jsqEG cQwrY5D5zycaHBRfmQuEMf8qupCe+2jzkBGRvcqoSbI/8vrfvRJ0Ma65FOcFpb8RV4HS 4PhA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=97nCMNpogWrrVx+FHc0u2XQ1Ft0nrve1ehQ7gesqUm0=; b=lxrm2c4LjNZwNTmGJcbUFPnLCRK+XMjoCT7K8eoSm+9wLBc6SMUlpb1vKMDRepM8yN m3SRBzAdrYNBz3EV/AIyye/H1F7FTCj4gPSFS2LNv6mySK1R76XeiP5ohVo7dCTIYk/A OfDlEZqEzofdUwX4hSgRy8i5mCUldlMzukTLqLWw+SyVj7RlSqwaB1ktVtpim6fwbQwy W0VqtdaLsjfDLYBrFqyIykCR59ReFWYnoNGjs/HmvYEppaWH9G0kWX9akRZ+HR64P3Pi /cNlUzWH/x0ojP86Iypp0lsr+4h38A7NkA6E72BZKhITFGJrUicGk6IGETMBdSNut7gS 5Q2A== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.132 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=97nCMNpogWrrVx+FHc0u2XQ1Ft0nrve1ehQ7gesqUm0=; b=vEdFljaYkhuo2oZOkIKPzMISMMYJA0LDWFa0HWwO4/Fw4+KFgGqJu5acAjGz/aYzPk +8v6TRceHVajZLwCyhiapNeUml+oa+r71gcKikYCxCT3vjWfDtvvlnsmw5i5dmO5gK87 hLp49yc18S89zE29fEQQiRFJ/u8tTIrawk/lFF/7yaAuXhoasj8K/XMB1BmKep5XscgM OfFc0WdASbUQBxZZXUoLLKUbpQ4KlPHJdUjLH7+9LmkKdKCTp3saOkrfkdIP2nYD080C EhGX7yADRePJQzQXd0kqEBK6rzDTaLMeFxWzsYZqd/heG+dRyI1MAX1FJ43N+xjbbDOu VKkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=97nCMNpogWrrVx+FHc0u2XQ1Ft0nrve1ehQ7gesqUm0=; b=kYnbH9pYXflMbiD6sVJv3bP5fAw4tQGldWGhv54B5zV5wBdDwSxUtQkuV0kJS4/lPb ZdXQF81m7l413VcRJOHP6FzkmiCkfbyBG1/qAMmZ+vYlDnV6DbxquGg6qatah7/KrNk6 2yHMbuRxC/oF3ZY/UsXzbrB2o3GwkF+5v8u85MDXWpgKug9w3RiBIJTjOP5hrTUOaj/3 3sA5mKl6pMKu3z76Fg5lfHW2vMRkTxvCgVU6o4lumg30e4NSZy/A4waRwvdSn2ExmlWr frXvfyyuGCoRwYzGruEWF8PDo+G4bfZVN4NUqgozd7LL0PbYaAwR10r6Qz/uOxPtys7g V X-Gm-Message-State: ALKqPwdWBf5lY31W80r0r4Z6qpa9iguNf4aTC3HgobdhloMPC7axj4pl 0Mm6wIkj7Fk3LoQSsjfwBqg= X-Google-Smtp-Source: AB8JxZqBeScwXHKoizYqaOqtHF/472u9YJqLCa7MrRpxJ3slPA6VuDi4d9eW6LKAecDxOGvU5xlDtw== X-Received: by 2002:a1c:e701:: with SMTP id e1-v6mr579228wmh.32.1526646072275; Fri, 18 May 2018 05:21:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1c:e341:: with SMTP id a62-v6ls471005wmh.11.canary-gmail; Fri, 18 May 2018 05:21:10 -0700 (PDT) X-Received: by 2002:a1c:9c2:: with SMTP id 185-v6mr4486379wmj.53.1526646070634; Fri, 18 May 2018 05:21:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526646070; cv=none; d=google.com; s=arc-20160816; b=QxlzZhTogYMCWe4tztIyEuJ9WKB7TfLbsB5CTGSfMND9iQ0OFTOn91IyqMkvGUr69q uC+MBF5JnIIb+j5Nf0QPWA5o3nMsRYJN3/7qxRD3nLp0aBeJy+k4Ym3PAKcgv6kpqNah IkF2gv2uL9r1ljdJSckkOHrOBiwO3JuN+6+DG+FyuLYesWAdSnz6YTrrC9Gtumsllt7D j9gc9Hn7hFj1krTQaTJYWN3smSAEcnAm9HfEO5lIT5TmdQLjFr351YaQ0LvuQWc2h3RM oIj/k/Q7JWAisjWV7i/6okT2EcD9brTYLPOjb5iNg93HNRBMBdfJ9ML7xEIsZ8TMlKYG i+aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=rbwyMglGY7dpJmOtkyJgzj60oy4dKqTHGgZke4+OizE=; b=dx25kG2mK2V81gFqUhjcqP6GmMszQ4fJiMOhsVGgOsVe6LZnUyXCNbnmSuyePF7tjP kKpAdDWR8oZiuhBxGHmbmQwPlWec0DxC+DL8Tc9+eVAuinmXw9GYomstw6xFUR0fObhE H8BN2+/bAbIKHujX3nFAxGSgYNYKIqJ9N1lkK3f92rIlL4g/DzQBx7kHBwcm4NR/N9gD j8D9fjKlY0xeBRLmaVVr+gmVapp4eLjD/w9jSyCeGSp88//V7q7qoW/oOVtRoFKriUqM LWD2O39XnBB6LkG4R19CWTVmqAFZsews7kuWGJnrTM18Dpu+H+Tu46xTfW9cH5ClHjms aKyw== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.132 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr. [80.12.242.132]) by mx.google.com with ESMTPS id a73-v6si6489162wrc.145.2018.05.18.05.21.10 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 18 May 2018 05:21:10 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.132 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.132; Original-Received: from imac-de-vicente-botet-escriba.home ([83.205.41.86]) by mwinf5d87 with ME id noM81x00r1rYW1v03oM9gq; Fri, 18 May 2018 14:21:10 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 18 May 2018 14:21:10 +0200 X-ME-IP: 83.205.41.86 In-Reply-To: Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.132 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:38125 Archived-At: This is a multi-part message in MIME format. --------------FEEA91565658746D77502380 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 17/05/2018 =C3=A0 12:30, tortoise741@gmail.com a =C3=A9crit=C2=A0: > 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=A9= crit=C2=A0: > > =C2=A0=C2=A0=C2=A0 I'm wondering if there is, or should be a standa= rd way to > convert > > a variant into an optional? > > Or if its a bad idea why there shouldn't be. > > > > > > > =C2=A0=C2=A0=C2=A0 std::optional getString() const > > =C2=A0=C2=A0=C2=A0 { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::optional ret; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto got =3D std::get_if= (&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 > > optional for the return. > > There is an inefficiency here in that the type contained has to be > > checked twice to use this. > > > > There are other ways to do this. You can expose the variant > member and > > use a visitor > > but using a visitor feels like overkill for this. Also the > variant is > > an internal implementation detail. > > An equally valid implementation would have two different optional > > 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 getString() const > > =C2=A0=C2=A0=C2=A0 { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return make_optional(this->bar); > > =C2=A0=C2=A0=C2=A0 } > > > > or bikeshedding: > > > > =C2=A0=C2=A0=C2=A0 std::optional getString() const > > =C2=A0=C2=A0=C2=A0 { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return to_optional(this->bar); > > =C2=A0=C2=A0=C2=A0 } > > > > The conversion is simple, but we don't need to do the conversion > until > requested. We can see a variant as some kind of ValueOrNone > type > (that can not change of alternative) once we select one of the > alternatives T. Lets name this function select(SumType). > > The conversion would be done only when requested, e.g. by an implicit > conversion. > > =C2=A0=C2=A0=C2=A0=C2=A0 optional o =3D select(SumType); > > > However, we could as well > > =C2=A0=C2=A0=C2=A0=C2=A0 auto von =3D select(SumType); > > von is not an optional. It is something else, a reference to a > sum-type, with the perspective of only one of the alternatives. > Now we > can use von as a ValueOrNone, with the usual von.has_value() and > *von. > 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:= :get_if(&von) and > =C2=A0=C2=A0=C2=A0=C2=A0 *von equivalent to std::get(von). > > > > I very much like the name select. > > I see your argument that a ValueOrNone isn't strictly an optional but=20 > if it isn't don't we complicate the language > with yet another "maybe" type? Wouldn't the language be cleaner with=20 > just one? > I guess the answer is adding optional references as previously mentioned? > Well, with the select function, you don't need to do any conversion,=20 even not to optional. Note that the type obtained with select, can=20 be an implementation detail. We don't have to name it. And of course, it=20 can be convertible to optional or optional if we had it. Vicente P.S. I've a variadic select that applied to std::any results in a sum=20 type that is equivalent to a nullable variant. std::any a; auto v =3D select(a); // equivalent to variant Once we have done that, we can visit a std::any :) The problem is that the complexity is not O(1) but O(n) :( --=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/c30c63a6-7695-b0be-7d3e-b57f1ed481b0%40wanadoo.f= r. --------------FEEA91565658746D77502380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 17/05/2018 =C3=A0 12:30, tortoise741@gmail.com a =C3=A9crit=C2=A0:
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=C2= =A0:
> =C2=A0=C2=A0=C2=A0 I'm wondering if there is, or should be a= standard way to convert
> a variant into an optional?
> Or if its a bad idea why there shouldn't be.
>

>
> =C2=A0=C2=A0=C2=A0 std::optional<std::string> getStrin= g() const
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::optional<= std::string> ret;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto got =3D std:= :get_if<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
> optional for the return.
> There is an inefficiency here in that the type contained has to be
> checked twice to use this.
>
> There are other ways to do this. You can expose the variant member and
> use a visitor
> but using a visitor feels like overkill for this. Also the variant is
> an internal implementation detail.
> An equally valid implementation would have two different optional
> 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> getStrin= g() const
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return make_optio= nal<std::string>(this->bar);
> =C2=A0=C2=A0=C2=A0 }
>
> or bikeshedding:
>
> =C2=A0=C2=A0=C2=A0 std::optional<std::string> getStrin= g() const
> =C2=A0=C2=A0=C2=A0 {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return to_optiona= l<std::string>(this->bar);
> =C2=A0=C2=A0=C2=A0 }
>

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

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

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


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
sum-type, with the perspective of only one of the alternatives. Now we
can use von as a ValueOrNone, with the usual von.has_value() and *von.
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::get_if<T>(&von) and
=C2=A0=C2=A0=C2=A0=C2=A0 *von equivalent to std::get<T>(von= ).



I very much like the name select.

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

Well, with the select function, you don't need to do any conversion, even not to optional<T&>. Note that the type obtained with select, can be an implementation detail. We don't have to name it. And of course, it can be convertible to optional<T> or optional<T&> if we had it.

Vicente

P.S. I've a variadic select that applied to std::any results in a sum type that is equivalent to a nullable variant.


std::any a;
auto v =3D select<T1, ..., Tn>(a); // equivalent to variant<none_t, T1&, ..., Tn&>

Once we have done that, we can visit a std::any :)
The problem is that the complexity is not O(1) but O(n) :(


--
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/c30c63a6-7695-b0be-7d3e-b57f1ed481b0= %40wanadoo.fr.
--------------FEEA91565658746D77502380-- .