220 33573 <5aa1302e-36e6-499d-8936-ebd523f293f9@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Catch block for multiple exceptions Date: Thu, 3 Aug 2017 16:49:45 -0700 (PDT) Lines: 295 Approved: news@gmane.org Message-ID: <5aa1302e-36e6-499d-8936-ebd523f293f9@isocpp.org> References: <4126837.jZlGhgVnua@tjmaciei-mobl1> <54580edb-4a76-4241-b5c8-19ccbc1a562e@isocpp.org> <4c872807-7d50-4b58-bbb5-595a8bac1246@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_257_257773712.1501804185993" X-Trace: blaine.gmane.org 1501804188 19073 195.159.176.226 (3 Aug 2017 23:49:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 3 Aug 2017 23:49:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBGXNR3GAKGQE67R4IDA@isocpp.org Fri Aug 04 01:49:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddPs6-0004cs-KK for gclcip-std-proposals@m.gmane.org; Fri, 04 Aug 2017 01:49:42 +0200 Original-Received: by mail-io0-f199.google.com with SMTP id s23sf1496723ioe.8 for ; Thu, 03 Aug 2017 16:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=7N8+xhG9K2WPD2NDSviEL1vpXLJHQl07Oh0N6mhG4qk=; b=vuw3M347sViQH0zfDOqj9la0w2Ls57zUKbzYQ4K7I6RRi198hMZaGCrkXyrQRyDZ6f cCzVmNQBpJPfXuwanxr1jsvyMuQQ55Yk1VdI8dNURys3lWqt7UruNKGZ9H0tbgNpLqAe PgtYQTnOZ7y9zMUH3XaKUfS3h5AJ03HYIPB4R+oZ/lUQO2wcNNWcGMKiWsA8Sfb7pJ1a Orj35Hpxe+0ABdPF3DfGVg6K6IgIKwBwWXRmMarlfjOqAeXZVfiHq5pB8ombkehJO1w9 zysmTshrTJ8D9ZYvGrg/Ok9vX8s/Dc7C3yDUtci7/IN5paoiNHme0MW6P4agA6DNnLF7 rqHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=7N8+xhG9K2WPD2NDSviEL1vpXLJHQl07Oh0N6mhG4qk=; b=R7Ry7ML+/2/eA1ey5LItRH8Qfp0pF8qzrEHBRpurq2jMRsxTu2Y+xe1DdAajykvFN3 N+jHkJE2doOjvF7cvmZTkUy9BqAy4Yh7ryFKA9ZlnhjG26+XdVgZOmIB5y+5sXx3Q4br 702eE2GpMgXVtmBzaZv4pgjjD6lgQpsSsOfW0PNv77jWrt0ot8aFKxUWUUO72cRalHap 2JANcVfDQpWbIQZjLjX/M7iI/yQF5c7M3dxBQYAZIrSrN2tmZHPTXKYm5ec++JgnkTHz hLk+cmOIL5bvmzBjPcwG/HOKiak8csnYaTueSycSDoC9fRyjAhO+vhNOzyOzxmmieBjd b3iw== 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: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=7N8+xhG9K2WPD2NDSviEL1vpXLJHQl07Oh0N6mhG4qk=; b=RGUrR3CPt3QA6J0fjC7KMC1aFw+ia506LVF88MuKSwFtKfXDRmALYrjQmPkLOMq6wy G09JEfgNETSC7N7UM2kAh9KptjCi7Kn7OhlNyaIHoZtaR+utrvvcJdWKn/wLu8Wztv/A oq04Zr0BkeFSas4eW2RFuHsJqp110aw5uJMG+Iof/Nt9s+RSs7M5Xr8Yn9vWZ0xLaQVV UpM5iYOWuIwnDfcL/+f6n6BkmE9KXZbYd1YADz6t9bVBgVHxoRq5NRpgabKDaIc/07nq a3gzuRQbc7+4DER9dSeE+x6vVDF8yTKM5vg/N77WY+y1YnkUMtAhqq0wEM1MdDXqGQ2M IKSQ== X-Gm-Message-State: AIVw1137dQXzQTZBh+kFQFrDJ/yKZMzhCKsQ3IMhlX+SQaRoMt+0Gpfm jefHALS3Exthm0LF X-Received: by 10.107.28.6 with SMTP id c6mr439423ioc.70.1501804188157; Thu, 03 Aug 2017 16:49:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.192.65 with SMTP id q62ls2377889iof.0.gmail; Thu, 03 Aug 2017 16:49:46 -0700 (PDT) X-Received: by 10.31.169.17 with SMTP id s17mr2381vke.11.1501804186491; Thu, 03 Aug 2017 16:49:46 -0700 (PDT) In-Reply-To: <4c872807-7d50-4b58-bbb5-595a8bac1246@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:33573 Archived-At: ------=_Part_257_257773712.1501804185993 Content-Type: multipart/alternative; boundary="----=_Part_258_1000085904.1501804185994" ------=_Part_258_1000085904.1501804185994 Content-Type: text/plain; charset="UTF-8" On Thursday, August 3, 2017 at 7:17:43 PM UTC-4, Arthur O'Dwyer wrote: > > On Wednesday, August 2, 2017 at 4:38:01 PM UTC-7, Ville Voutilainen wrote: >> >> >> Note that both of our solutions suffer from the problem that the code >> in the catch-clause >> cannot break, continue, goto or return like plain code could. An >> if-else chain of any_casts >> from exception_ptr would be able to do that. >> > > Do you think LEWG would be amenable to a proposal to make std::any_cast an > all-purpose "type-un-erasing" mechanism in C++2a? > Right now we have a different type-un-erasure mechanism for each > type-erased type, and more proliferating with each revision of the Standard: > > std::any a = xx;assert( std::any_cast(a) == 42 ); > std::function f = xx;assert( *f.target() == xx ); > std::shared_ptr p(new int, xx);assert( *std::get_deleter(p) == xx ); > > (from > https://stackoverflow.com/questions/44788017/retrieve-typeid-of-shared-ptr-deleter > ) > (and from this thread, we can add std::exception_ptr to the list of > type-erased types) > > I'm not sure "any_cast" would necessarily be the right spelling, but it is > pretty awkward IMHO that various library designers keep reinventing it over > and over with different spellings. > > Well, `any_cast` is most definitely not the right spelling. As shown with `shared_ptr`, the deleter is something that is separate from the main purpose of `shared_ptr`, so getting at it requires an interface that shouldn't look like `func_name(ptr)`. You might do it by having `get_deleter<>` return an implementation-defined type that you can call `any_cast` or whatever on. There's also the fact that it has to have different behavior. With `any_cast`, you can move the object out of the `any` (the `any` is still engaged with a moved-from value); with `function`, you don't have that power. But this is all getting pretty far afield from the main topic. -- 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/5aa1302e-36e6-499d-8936-ebd523f293f9%40isocpp.org. ------=_Part_258_1000085904.1501804185994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, August 3, 2017 at 7:17:43 PM UTC-4, Arthur O&= #39;Dwyer wrote:
On Wednesday, August 2, 2017 at 4:38:01 PM UTC-7, Ville Voutilainen wrot= e:

Note that both of our solutions suffer from the problem that the code
in the catch-clause
cannot break, continue, goto or return like plain code could. An
if-else chain of any_casts
from exception_ptr would be able to do that.

Do you think LEWG would be amenable to= a proposal to make std::any_cast an all-purpose "type-un-erasing"= ; mechanism in C++2a?
Right now we have a different type-un-erasu= re mechanism for each type-erased type, and more proliferating with each re= vision of the Standard:

std::any a =3D xx;
asser=
t( std::any_cast<=
span style=3D"font-family:inherit;font-size:inherit;font-style:inherit;line=
-height:inherit;vertical-align:baseline;color:rgb(48,51,54)"><Type>(a) =3D=3D 42 );

std::=
function<long=
()>=
 f =3D xx;
asser=
t( *f.target<Type>() =3D=3D xx );

std::=
shared_ptr<int&=
gt; p<=
/span>(new<=
span style=3D"font-family:inherit;font-size:inherit;font-style:inherit;line=
-height:inherit;vertical-align:baseline;color:rgb(48,51,54)"> int, xx);
asser=
t( *std::get_deleter<Type>(p) =3D=3D xx );
(and from = this thread, we can add std::exception_ptr to the list of type-erased types= )

I'm not sure "any_cast" would nece= ssarily be the right spelling, but it is pretty awkward IMHO that various l= ibrary designers keep reinventing it over and over with different spellings= ..


Well, `any_cast` is most definitely = not the right spelling. As shown with `shared_ptr`,=C2=A0 the deleter is so= mething that is separate from the main purpose of `shared_ptr`, so getting = at it requires an interface that shouldn't look like `func_name(ptr)`.<= br>
You might do it by having `get_deleter<>` return an implementa= tion-defined type that you can call `any_cast` or whatever on.

There= 's also the fact that it has to have different behavior. With `any_cast= `, you can move the object out of the `any` (the `any` is still engaged wit= h a moved-from value); with `function`, you don't have that power.
<= br>But this is all getting pretty far afield from the main topic.
=

--
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/5aa1302e-36e6-499d-8936-ebd523f293f9= %40isocpp.org.
------=_Part_258_1000085904.1501804185994-- ------=_Part_257_257773712.1501804185993-- .