220 39304 article Path: news.gmane.org!.POSTED!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Standardising a type-erased iterator Date: Mon, 23 Jul 2018 11:01:58 -0400 Lines: 406 Approved: news@gmane.org Message-ID: References: <09db196a-e818-4d7a-9af1-48f07b2f4c3d@isocpp.org> <24d8f121-aba9-4ead-b107-bc4b72014870@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000052f7820571abed0b" X-Trace: blaine.gmane.org 1532357994 23377 195.159.176.226 (23 Jul 2018 14:59:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2018 14:59:54 +0000 (UTC) To: Standard Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQIORW6X3ICRUBACCIBV2@isocpp.org Mon Jul 23 16:59:50 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhcJS-0005yA-9F for gclcip-std-proposals@m.gmane.org; Mon, 23 Jul 2018 16:59:50 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id j5-v6sf759824oiw.13 for ; Mon, 23 Jul 2018 08:02:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1532358121; cv=pass; d=google.com; s=arc-20160816; b=JdOYl3Dir7p4xJcJyT7XHDVYKQKNnaf8/ImZBTxu5hgKhpwjQTX5o7AgHCzWYgosSq 2LRvtE7tJoG05evGw4pv6PClxSCdumfBzQqh5XerVJzO05q/EcXqH4Ty4dMQ4hYqUGQl nb14Rx+g6PgQYEKJDKF4TjhwuZHQgnzz6N/KaH3SVBFBU0jSOyYeTRFYNxU4nZLy710g R0MEj+vWeC2dNsvR7ZqVVLjubHauDTvktLU93U8BYYyKl1R4u+knwSBHjDCZOuekfSbL YQV4o8+fXOhvbG0FeV639qfpbj//33kQ+nCEna9fD0ZF1eD8I+PI8Uj4v+9Y7VAw306V wI4Q== 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:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=W9IpodNHbriCrU8OC+PMken8v41p9RKtR2I3O6ILM38=; b=LqcUUVO239BVJVAW0bOG4zKOZm1c7NSqXwMwVPFRh3XBMy5c2UycPZjhLM1+XadDkb GZMl2uabawRFU1yCcxfhhV6FczyEZriwgHY8YsUXl0vK0LKAqTJZkm36/iAgQDNNn182 C1uX4ZDfDpPcz5IdtCJEs/55YDfUNQjGabouHoE/Ppdb+LSRu2PIlLc51SjcTMU9E1lH 97exDEUfzkuU5BOdFmaOdRUP97bBOcVkp7PKX/f619G9trLgstZoR0p2vs0GZG4m039A CEzdVeBzvoSLrMxLDpnJf2O8OpTS6rJXEkwbGLlwoi8sv4EHL7oUB1d7PrD5zFwgW0wR iLeQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=obfDzy4b; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=W9IpodNHbriCrU8OC+PMken8v41p9RKtR2I3O6ILM38=; b=oMrnyIPBjowMuJIdzQuzfWnUElkmK15JREzG2bpY1R8AaGOh2Aet3jgd69fl3aLoQ9 dyZ24YEhB5ZRiiUHt0qPMAH10G1ImPCPTM0TujscKGaCapWcWrc8Cjldy7RgtrfCwmY6 ax7dcf01MHwMeFLtbVWQrf5z2LfEMqENttuuZ/6J5Z1HDvPtMO0fqkYIBy635yJemtle vZaTygmBnHMAvoACiRtzOZK5vK9QclXUK/Ar2zqDlhEUHMRJfQ1bgA7r7T0RpZgzX1TL tBdMnUd2xEss4zbOi8HywM9oVXEMYPitScHWMTGXdvKEuJdVKu3mC+GlJPnMqpYoZJqx NtKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=W9IpodNHbriCrU8OC+PMken8v41p9RKtR2I3O6ILM38=; b=kjz6SbIKOUSrzVOxtBod80JlGRa22I2nTMOxW16R6mR1hRhw6kwYu2ZMYBYAveoG9k UDjbeyil5/ye7JKEh5cl6DthHSX3pZ1+vGtTZ5iGYIWgbj5zwwIABxEMz4eEvtajZ6rG V6Ss9Z0xsc09u7M3d9jSEhip1nlA0fqsfRJJZqMuLuV4K/9vAadnNxUP6NSKET/DJlCO MwZN81lGcxU4EA2tb+CL04bSdWbibiCRnlGq1U2LzDnueIy0wTmmSDehq9FnKoVT408u Dp/SiGByJ3WL06e4F3Fw3tAw/ZQ18GYuyS5SXXBXGXLLqvIH1QWB0dFqEKIhOpMwvaVN 2UMg== X-Gm-Message-State: AOUpUlGzv4FvFPGniJxsk7zcIKwHaM5e3Gxa2ymwKtbh+XWRuGMccWE7 X/JWjXR32vNBG1LNOFjUmGnUpA== X-Google-Smtp-Source: AAOMgpcwems6NYVmpOX5h2hzfNMcqM4HYLnHeAY75F5R+iKdm02Y4AiMcjHxm5f14jwxBS45Nw4lOA== X-Received: by 2002:aca:a17:: with SMTP id 23-v6mr9816964oik.80.1532358120936; Mon, 23 Jul 2018 08:02:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:c0d4:: with SMTP id q203-v6ls3124306oif.14.gmail; Mon, 23 Jul 2018 08:02:00 -0700 (PDT) X-Received: by 2002:aca:b702:: with SMTP id h2-v6mr8599365oif.66.1532358120021; Mon, 23 Jul 2018 08:02:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532358119; cv=none; d=google.com; s=arc-20160816; b=sxYdOrPwO2KE3nT9Yz/vsIRZ2JSJrP9Oef4PgUmz2Rub7z6A5PNmzsrJAHazHFkrsL DVBtMhSZTaK9Gci3aKl2rTye/+Sld+eXdaG3DsL6pPKw3Wu8TtHG9qDYr2BVHSprz/Vc 3+1BILeWYdaSHBkrwsXxzfW13bjaCja1AywmuMp8XDUgwofCUMZU1fkSeGHIWkri5QDX iHY78tLy0D7rR9JncduDGYt77SNB/JgQdh1uChpdpXo3pgLTzLRj7cyBUbEW25InxNx5 +flpQ/fpm1jW7VqoYTkCfmuVmKnUa77SRXEg4SS+u150BYkousuRmiZ6CfFi3FVVHXD6 IgkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=nXl47JAYBo0nsN6fvePyGi7sOlV4LgkoME0cifVFgJ4=; b=H0Xf4GpP1KhsNSh+OBPAxu3QIjfh3GBf9fNkfetB4zxzyo8kXxn8YqnxXDReeuEgiV 04ByXsooEHtL0oBWLfP3N3dXro7W3EA7+9UzVKUjbL1MM5xAtWIvNVa634JKEdATnqcM c35on79Y4W7oLZfOVHT/z+zI5i+8DzRFt5OhtmDkq11mreE6nLBDmD0p7YVpkN0lQrup 2SLN0PRbrFgas/7olWs9R+AAfvuxZRYDQwM6+QNkzsR0HM6LgbMut8856x0WqaftFl8c JWyqvd6EOkAO0Odz5+V1vf0/wz1mKn+C9yrsXwY8K34OBHHMtHyeJb9MK5LRxDNPVGwy jqyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=obfDzy4b; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id x12-v6sor4770516oie.29.2018.07.23.08.01.59 for (Google Transport Security); Mon, 23 Jul 2018 08:01:59 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:aca:af15:: with SMTP id y21-v6mr9414047oie.324.1532358118535; Mon, 23 Jul 2018 08:01:58 -0700 (PDT) Original-Received: by 2002:a9d:ea6:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 08:01:58 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=obfDzy4b; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:39304 Archived-At: --00000000000052f7820571abed0b Content-Type: text/plain; charset="UTF-8" On Mon, Jul 23, 2018 at 10:54 AM, Richard Hodges wrote: > > > On Mon, 23 Jul 2018 at 16:16, Tony V E wrote: > >> I've wanted type-erased iterators a few times, on various projects, >> various companies. >> >> Currently we deal with 3D points a lot. Often in vectors. Sometimes in >> other containers. Sometimes the 3D point is just part of a bigger struct. >> So we get a vector of FooBars and each FooBar has a 3D point (or 2 >> different 3D points, like 'source' and 'dest' and we need to pick which we >> are processing.) >> >> For many algorithms we use, the cost of "get next point" is small >> compared to other processing. And the amount of code in the algorithm is >> high for a template. >> >> So I see lots of code that copies tens of thousands of points from one >> container into another, so that it is in the right format, ie so that it >> can pass in a vector. >> We might also transform each point tmp = f(*it) before processing it. >> That could also be in the iterator. >> > > This is beginning to make sense. > > Now giving it more thought, I see problems. > > A map's value_type is a key/value pair but a vector or set's value_type is > a value. > > Conceptually we could argue that all containers have a key and a value: > > vector : key = std::size_t, value = V > map : key = K, value = V > set : key = V, value = V > > Then we could distinguish between polymorphic key iteration and > polymorphic value iteration. > > This might argue for > > std::polymorphic_forward_sequence_key_view, > std::polymorphic_forward_sequence_value_view and > std::polymorphic_forward_sequence_key_value_view > > ...etc for all classes of iterator category. > > It's starting to look like a lot of work. > std::poly_sequence. If you want key, make T = key; if you want value, make T = value; if you want key+value, make T = std::pair. From the point of view of the algorithm that will _use_ the iterator, it only needs one type - whatever T it needs to process. Put the magic of converting from map to poly_sequence inside the iterator. > >> >> On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges >> wrote: >> >>> >>> >>> On Mon, 23 Jul 2018 at 09:01, Thomas Russell >>> wrote: >>> >>>> The motivation is similar to having any standard type-erased facility; >>>> it gives a concrete interface that accepts an arbitrary set of classes that >>>> conform to the required concepts. >>>> >>>> The closest existing parallel in the standard library is >>>> `std::function`, modelling the Callable concept. >>>> >>>> Having such a facility as a vocabulary type provides various benefits >>>> over function templates accepting Callables: >>>> - Reduced generated code-size (this can even go some way towards >>>> reducing the performance penalty). >>>> - Works with the OOP paradigm (virtual functions cannot be function >>>> templates) >>>> - Reduced compile-time >>>> - Can work across dynamically-linked library boundaries, providing the >>>> correctly corresponding build parameters are met. >>>> >>>> I think these are good motivations, but am interested to hear opposing >>>> opinions. >>>> >>> >>> I think it would be fair to say that they are theoretical or >>> hypothesised motivations, not actual concrete use cases where there is a >>> demonstrable benefit in providing a standardised type-erased iterator suite. >>> >>> I'm thinking in terms of "here's some current software that sucks >>> because we don't have type-erased iterators, and presented here is a better >>> version using my implementation of such iterators". >>> >>> I say this not to be argumentative. >>> >>> I say it because like you and many others, I have played with similar >>> ideas because they were fun or interesting ideas. Including for example a >>> type-erased iterator for iterating across a tuple (operator* returns a >>> boost::variant of references). >>> >>> However, in 30 years on and off writing commercial software, I have >>> never encountered an actual use case while using c++. >>> >>> This is probably because I reach for c++ when seeking concrete >>> guarantees on type safety, and python, perl or javascript when I'm seeking >>> type flexibility and expressiveness. >>> >>> But it could be that I am thinking myopically. I have experimented in >>> the past with providing more "script-like" library objects to the odd >>> project. Again, out of curiosity more than need. >>> >>> You see what I'm saying? Is this in reality a fun personal project, or >>> is there a tangible benefit to me if I find this in the std toolbox? >>> >>> >>>> >>>> -- >>>> 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 email 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/c9664ef6-f769-4942- >>>> 8e44-56761d091efc%40isocpp.org. >>>> >>> -- >>> 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 email 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/CALvx3haDm01D7jCvJJA3JJycraXVZ >>> _WHz9A4md5h1WXhCR29cg%40mail.gmail.com >>> >>> . >>> >> >> >> >> -- >> Be seeing you, >> Tony >> >> -- >> 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 >> email 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/CAOHCbivaZbbS- >> zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com >> >> . >> > -- > 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 > email 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/CALvx3hZWBkQB0SGDqaD5iY_- > kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com > > . > -- Be seeing you, Tony -- 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 email 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/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com. --00000000000052f7820571abed0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 23, 2018 at 10:54 AM, Richard Hodges <= hodges.r@gmail.com<= /a>> wrote:

I've wanted type-erased iterators = a few times, on various projects, various companies.

Currently we deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 So= metimes in other containers.=C2=A0 Sometimes the 3D point is just part of a= bigger struct.=C2=A0 So we get a vector of FooBars and each FooBar has a 3= D point (or 2 different 3D points, like 'source' and 'dest'= and we need to pick which we are processing.)

For many algorithms we use, the cost of "get next point" is smal= l compared to other processing. And the amount of code in the algorithm is = high for a template.

So I see lots of code tha= t copies tens of thousands of points from one container into another, so th= at it is in the right format, ie so that it can pass in a vector<Point3D= >.
We might also transform each point tmp =3D f(*it) before pr= ocessing it.=C2=A0 That could also be in the iterator.

This is beginning to make sense.=C2=A0

Now giving it more thought, I see problems.

A map's value_type is a key/value pair but a vector o= r set's value_type is a value.

Conceptually we= could argue that all containers have a key and a value:

vector<V> : = key =3D std::size_t, value =3D V
map<K, V> : key =3D K, value =3D V
set<V> : key =3D V, value =3D V

Then we could distinguish between polymorphic key iteratio= n and polymorphic value iteration.

This might argu= e for=C2=A0

=
std::polymorphic_forward_sequ= ence_key_view<K>,=C2=A0
std::polymorphic_forward_sequence_value_view<V>= and=C2=A0=C2=A0
std::= polymorphic_forward_sequence_key_value_view<K, V>

...e= tc for all classes of iterator category.
=C2=A0=C2=A0
It's starting to look like a lot of work.


std::poly_sequence<T>.=C2=A0 I= f you want key, make T =3D key; if you want value, make T =3D value; if you= want key+value, make T =3D std::pair<key,value>.
From the point of view of the algorithm that will _use_ the iterator, = it only needs one type - whatever T it needs to process.

=
Put the magic of converting from map to poly_sequence<mapped_= type> inside the iterator.



<= br>


On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges &= lt;hodges.r@gmail.c= om> wrote:


On Mon, 23 Jul 2= 018 at 09:01, Thomas Russell <thomas.russell97@gmail.com> wrote:
The motivation is similar to having any standa= rd type-erased facility; it gives a concrete interface that accepts an arbi= trary set of classes that conform to the required concepts.

The closest existing parallel in the standard library is `std::function`, m= odelling the Callable concept.

Having such a facility as a vocabulary type provides various benefits over = function templates accepting Callables:
- Reduced generated code-size (this can even go some way towards reducing t= he performance penalty).
- Works with the OOP paradigm (virtual functions cannot be function templat= es)
- Reduced compile-time
- Can work across dynamically-linked library boundaries, providing the corr= ectly corresponding build parameters are met.

I think these are good motivations, but am interested to hear opposing opin= ions.

I think it would be fair = to say that they are theoretical or hypothesised motivations, not actual co= ncrete use cases where there is a demonstrable benefit in providing a stand= ardised type-erased iterator suite.

I'm thinki= ng in terms of "here's some current software that sucks because we= don't have type-erased iterators, and presented here is a better versi= on using my implementation of such iterators".

I say this not to be argumentative.

I say it bec= ause like you and many others, I have played with similar ideas because the= y were fun or interesting ideas. Including for example a type-erased iterat= or for iterating across a tuple (operator* returns a boost::variant of refe= rences).

However, in 30 years on and off writing c= ommercial software, I have never encountered an actual use case while using= c++.

This is probably because I reach for c++ whe= n seeking concrete guarantees on type safety, and python, perl or javascrip= t when I'm seeking type flexibility and expressiveness.

<= /div>
But it could be that I am thinking myopically. I have experimente= d in the past with providing more "script-like" library objects t= o the odd project. Again, out of curiosity more than need.=C2=A0
=
You see what I'm saying? Is this in reality a fun person= al project, or is there a tangible benefit to me if I find this in the std = toolbox?
=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-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.co= m/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44= -56761d091efc%40isocpp.org.

--
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-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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29c= g%40mail.gmail.com.



--
Be seeing you,
Tony

--
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-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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy= %3D%2BHnw%40mail.gmail.com.

--
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-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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXt= UoUr%3Dzg%40mail.gmail.com.



--
Be seeing = you,
Tony

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisY24xBK9= zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com.
--00000000000052f7820571abed0b-- .