220 30232 article Path: news.gmane.org!.POSTED!not-for-mail From: m.cencora@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: enum_cast proposal Date: Wed, 4 Jan 2017 07:20:11 -0800 (PST) Lines: 134 Approved: news@gmane.org Message-ID: References: <42463446.MPeEFdAbRV@tjmaciei-mobl1> <1730f9cb-837d-4af3-a771-107e21de0adc@isocpp.org> <64617344.0Ggdhq6B90@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2811_1217587467.1483543211405" X-Trace: blaine.gmane.org 1483543224 18033 195.159.176.226 (4 Jan 2017 15:20:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 15:20:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD7YFUMJRYMBBLFFWTBQKGQE6K4WHAY@isocpp.org Wed Jan 04 16:20:18 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f70.google.com ([74.125.83.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOnMH-0002v3-Rg for gclcip-std-proposals@m.gmane.org; Wed, 04 Jan 2017 16:20:10 +0100 Original-Received: by mail-pg0-f70.google.com with SMTP id a190sf1317199936pgc.0 for ; Wed, 04 Jan 2017 07:20:13 -0800 (PST) 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=w2J2JjTJfIq5jZhMe5gUJjp04My0Ilmbzsj0xcx85RM=; b=jNQpNa6CWbKH7uHu7L45FhxRZxVXS7JeZz7z4ugGcZZFXfx/JzIAXJZPg3C8XtWZQ8 zLJ2fU4OB+nI0hbX9QArOvvKQKAAVMD4e8CKsFA5JPCpzIvuHNrI9Gxp/T7ohedPFozC +VUIKgDkVid9kTBiWoVDr7h+m9NWGttNzGg23cu7KMXht/5Tst2LDiY6D8J4JcBLXpqR fkuL51wAUCdl2DFzvTBLtg8+P3cmFCKTY3pZja50nMye7EbM+Vtpo6FyOHX8rJGolDrw z9ruH50p/ofXFpGlEZs4iT/NPDSfE1e3PwNxRM/SA+n3X5PrhHAZre79RUXsFZmkFW06 31Sw== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=w2J2JjTJfIq5jZhMe5gUJjp04My0Ilmbzsj0xcx85RM=; b=Xtz0sjU2kbsoift39qLMoiOiai2hnOZO1DwS/dIxCLnVjD1q/xHF2PQNWt3fAmuMJT CIC+yB7H7tzHgIzCg2Zbu0LgTKfHQd8d5gOZjZ9+GynAPR33Hb++eD7HwYkNvOZRFliy 0VRFTSLcaAk7gZfY1hN9ZmKS2Lk5sCXhsRxLX/yJ5rM8SXLx98CGdEwoUAju0HihOxac XAb7+9PELF5Seo1iBk5K4nN1MZ50ki8BYsfj2Yc1rLO262//AUiiqwyrGA3BfD0Ty4gW 0yfQuJ+JFuJkaigpdEi4RgDvvmtY18OgxcDqxvCXF11Aa0hepiQ+lgl0S1IGfTS/vRU0 Mc4Q== 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=w2J2JjTJfIq5jZhMe5gUJjp04My0Ilmbzsj0xcx85RM=; b=CYdhezLTHUaFtIj7zKfJlF7XcV9Vj5C6TxvxXBch4MkHEhwFxZGYS075QAF7wUP857 ZXHPRY3gLXR4/8H+3bG2Tdy9RQ6ta7IyIavER3tk6TLAmgv/1bud842bgM98c+mh+jzb Svxt+gIMtn32E/PxPgFcA6MN9NpIaU6S2Vd9cftlZJ6NtYdky55sloddJjmggCllBWn6 ONRtLqGSmoQwEoU1r3HdtM1NNUlJw+YGjDyIvMR2sL84NnnmHkBif4fMp5yIHKyLvj/A z07GIPK3MjoWIMldJ9yUqYlhc0YYkjyYOJuReQtmZNq61wLDXL2tApwmuY/gyHmQZfQT H8Jw== X-Gm-Message-State: AIkVDXLG92W9syqF/+XgupQ40UbqCobwtBfphoHmukrPIyxoahnK8miHWCkLWgWDDdYcRQ== X-Received: by 10.99.117.11 with SMTP id q11mr37160693pgc.102.1483543213069; Wed, 04 Jan 2017 07:20:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.13.228 with SMTP id 91ls46828909ots.42.gmail; Wed, 04 Jan 2017 07:20:11 -0800 (PST) X-Received: by 10.157.39.129 with SMTP id c1mr3156492otb.15.1483543211854; Wed, 04 Jan 2017 07:20:11 -0800 (PST) In-Reply-To: <64617344.0Ggdhq6B90@tjmaciei-mobl1> X-Original-Sender: m.cencora@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:30232 Archived-At: ------=_Part_2811_1217587467.1483543211405 Content-Type: multipart/alternative; boundary="----=_Part_2812_1123395632.1483543211405" ------=_Part_2812_1123395632.1483543211405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu =C5=9Broda, 4 stycznia 2017 15:30:12 UTC+1 u=C5=BCytkownik Thiago Ma= cieira=20 napisa=C5=82: > > On quarta-feira, 4 de janeiro de 2017 00:44:09 BRST m.ce...@gmail.com=20 > wrote:=20 > > I thought about it, but I see no use case for just a check.=20 > > In all the use cases I can think of user wants the cast after the check= ..=20 > >=20 > > Do you have a example in mind where such a check without a cast later= =20 > > would be useful?=20 > > The problem is that a cast that can fail needs a way out. dynamic_cast ca= n=20 > fail by returning nullptr (for pointers) or by throwing std::bad_cast (fo= r=20 > references).=20 > > So you need to find a way to report that failure.=20 > > And I don't want exceptions in my code.=20 > That's exactly the reason why I have proposed to return optional. Why do you want to use some compiler invented type instead? If enum_cast is a function in standard library, why can't it use another type from same library? Regards, Maciej =20 > > --=20 > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 > Software Architect - Intel Open Source Technology Center=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/d03061cc-7442-4e10-9313-a3394afa11e3%40isocpp.or= g. ------=_Part_2812_1123395632.1483543211405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 4 stycznia 2017 15:30:12 UTC+1 u=C5=BCy= tkownik Thiago Macieira napisa=C5=82:
On quarta-feira, 4 de janeiro de 2017 00:44:09 BRST m.ce...@gmail.com= wrote:
> I thought about it, but I see no use case for just a check.
> In all the use cases I can think of user wants the cast after the = check.
>=20
> Do you have a example in mind where such a check without a cast la= ter
> would be useful?

The problem is that a cast that can fail needs a way out. dynamic_cast = can=20
fail by returning nullptr (for pointers) or by throwing std::bad_cast (= for=20
references).

So you need to find a way to report that failure.

And I don't want exceptions in my code.

That's exactly the reason why I ha= ve proposed to return optional<T>.

Why do yo= u want to use some compiler invented type instead?
If enum_cast i= s a function in standard library, why can't it use another
ty= pe from same library?

Regards,
Maciej
=C2=A0

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--
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/d03061cc-7442-4e10-9313-a3394afa11e3= %40isocpp.org.
------=_Part_2812_1123395632.1483543211405-- ------=_Part_2811_1217587467.1483543211405-- .