220 31265 article Path: news.gmane.org!.POSTED!not-for-mail From: Giovanni Piero Deretta Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0534: call/cc, type safety and exceptions Date: Wed, 1 Mar 2017 09:18:06 -0800 (PST) Lines: 124 Approved: news@gmane.org Message-ID: References: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> <4e6c13b2-4286-4df8-989b-97cbf3bf1cc7@isocpp.org> <312d04a6-8b20-4bf5-8357-507ba9938e84@isocpp.org> <762243ed-0c31-461d-b6fd-fdb8759857b2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1898_289746571.1488388687074" X-Trace: blaine.gmane.org 1488388696 21369 195.159.176.226 (1 Mar 2017 17:18:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 17:18:16 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIM7BG4YUCRUBBZ3EHBK@isocpp.org Wed Mar 01 18:18:07 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cj7t4-00048k-UF for gclcip-std-proposals@m.gmane.org; Wed, 01 Mar 2017 18:18:03 +0100 Original-Received: by mail-qk0-f199.google.com with SMTP id c85sf67435469qkg.0 for ; Wed, 01 Mar 2017 09:18:09 -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=FwTVjVOGdgRlNiSqWAT2UqYNdURhcW6oqI8qGSpp2eY=; b=cSd9iNUphf8mQMz05VozA0Kl8//v/8hcsn19+ZR5u/P4Ag7/38NA+eBsxt8OjMoFMv tUkESs+9JSxubg31CQFzPoCivMBkJCBwip9meGNr0j20JKa8lXkiuhddZysoJxHL2RRp 3+im0o3uI0o86uLs2iuRZozi86YEdmc/eRCzXqvPmf1jSve6Q1JLszrM9y1ujuLNyrJI hEJQ3iWNDg/TQyL1uUAnWtZRkRTK7xUHaXvYxBP54cGSdEP4fw73RZUfjwVN9TFKr7O8 KzNR6NiR5/GbG+uBXiUKLb6fYz6KfYAYuukHy8Cp4UpJaUw1npObyezDkefrFheDy0Zt Fh0Q== 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=FwTVjVOGdgRlNiSqWAT2UqYNdURhcW6oqI8qGSpp2eY=; b=Ru+X0hQVeQhuH2dubsqOh7kEQjJrGK6AD9HAKLAwRnAARm3XqMRdIZVpJCEKd/Crcc wENvVaG30oqCYZjUQ4HFiIYKHRyHcbX/xY8JIx7kfRoMdp7HaKu1mH1oqPCxlIHG0uXo w4JI8W3EC7ActyOavEC1lHmAWtq1iFEWhlkrXtMnLkWDNQCH/vkufatFy0wtCRJlx6AM 3h1Z6QnZxAVU2lCgDyBIgIoYG1BzKqnkn7ZEmj0L2uXH52EqMeW0NM86oYIgKovTfHLC 0U6fXddMUd7/aPlGMOYlW4b+smka1S6z2RG2jTUegVgrO6uv8+dyqqnbMb/InaA/iV5h dmzw== 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=FwTVjVOGdgRlNiSqWAT2UqYNdURhcW6oqI8qGSpp2eY=; b=Rc6vBFHSGZ7kJP/NL/SoUDfdTt+5/69fpCmk+yf/z1sl+cDxoxSFdUi97bR88PpnAz SVZmg9CxVhjagpSCU5mdMBPgK0bC6ollsJ6rvHmvRQCvlJ4xhYTkq62Mr/WvOAgOEI/4 2BHyd1wkj1ifBN9soIEYJqbLlYhYbwlwbiO8z1COGCnzbQ11O0zj6mmaLIKhagVPsryO 7rr8m+0KZp8PFWZX27QcROI1Q1aH+VpAv+p3GjhRn21xNfAPQ6TOODbLYzidqlW1UE+k wlXO78K0QRl3y2oGMvn25aDhCwC3nOzF37i35Ni9h8JlJKHHHBbAPv5n/4blhd/W/eHf Ep/A== X-Gm-Message-State: AMke39mMGeDWYDzORFJCSKSLGopz4dvSS0E0RDNRXMfhjWwRtaZxr6pV1wvvSzL+6R1LWw== X-Received: by 10.200.47.130 with SMTP id l2mr2800667qta.52.1488388688493; Wed, 01 Mar 2017 09:18:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.226 with SMTP id c89ls2602770otb.2.gmail; Wed, 01 Mar 2017 09:18:07 -0800 (PST) X-Received: by 10.157.4.129 with SMTP id 1mr1160254otm.17.1488388687530; Wed, 01 Mar 2017 09:18:07 -0800 (PST) In-Reply-To: <762243ed-0c31-461d-b6fd-fdb8759857b2@isocpp.org> X-Original-Sender: gpderetta@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:31265 Archived-At: ------=_Part_1898_289746571.1488388687074 Content-Type: multipart/alternative; boundary="----=_Part_1899_298338664.1488388687075" ------=_Part_1899_298338664.1488388687075 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas wrote: > > > > On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta > wrote: >> >> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote: >> [...] >> >>> >>> So we need the safe mechanism, and we need it shipped with the system. >>> But that should not be the *only* way; the lower-level form should >>> still exist. >>> >>> Now, maybe the type-safe version should be the *default*, so that if >>> you want the lower-level, unsafe API, we can clearly see that safety is >>> being sacrificed. So `callcc/continuation` would naturally be type-safe, >>> with `unsafe_callcc/unsafe_continuation` being not type safe. >>> >> >> we are in agreement then, I just want to point out that, given a type >> safe std::continuation implementation, the unsafe variant would simply >> be std::continuation, while the dynamic variant would be >> continuation, given a suitable implementation of any_ptr. >> > > I don't think you understood what I meant when I said "type safe". I > specifically *don't* mean that the continuation has a static and typed > set of parameters. What I mean is that getting the parameter back is > type-checked and therefore safe. But it's a *runtime* check, not a > compile-time check. > > This prevents compile-time tight coupling while still having safety on the > receiving end. > Hum, but this means that those that want statically check type safety (a very common use case, think generators), are left in the cold and need to roll their own continuation type on top of the unsafe one. I still don't see the need for a dynamically checked continuation type. For example, std::function is a vocabulary type designed for interoperability and decoupling, but it still check the signature a compile time. A runtime checked std::function is possible, but not desirable (incidentally Qt slot types used to be only dynamically checked and it was a pain). I don't see why continuation would be different (in fact there is a very strong affinity between continuations and functions). -- 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/f8a573b1-c4ff-48a2-8a6f-51433732ab26%40isocpp.org. ------=_Part_1899_298338664.1488388687075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas= wrote:

On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta = wrote:
On Wednesday= , March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
[...]

So we need the saf= e mechanism, and we need it shipped with the system. But that should not be= the only way; the lower-level form should still exist.

Now, = maybe the type-safe version should be the default, so that if you wa= nt the lower-level, unsafe API, we can clearly see that safety is being sac= rificed. So `callcc/continuation` would naturally be type-safe, with `unsaf= e_callcc/unsafe_continuation` being not type safe.

we are in agreement then, I just want to point out that, = given a type safe std::continuation<T> implementation, the unsafe var= iant would simply be std::continuation<void*>, while the dynamic vari= ant would be continuation<std::any_ptr>, given a suitable implementat= ion of any_ptr.

I don't think you = understood what I meant when I said "type safe". I specifically <= i>don't mean that the continuation has a static and typed set of pa= rameters. What I mean is that getting the parameter back is type-checked an= d therefore safe. But it's a runtime check, not a compile-time c= heck.

This prevents compile-time tight coupling while still having s= afety on the receiving end.

Hum, but t= his means that those that want statically check type safety (a very common = use case, think generators), are left in the cold and need to roll their ow= n continuation type on top of the unsafe one. I still don't see the nee= d for a dynamically checked continuation type.

For example, std::fu= nction is a vocabulary type designed for interoperability and decoupling, b= ut it still check the signature a compile time. A runtime checked std::func= tion is possible, but not desirable (incidentally Qt slot types used to be = only dynamically checked and it was a pain). I don't see why continuati= on would be different (in fact there is a very strong affinity between cont= inuations and functions).
=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/f8a573b1-c4ff-48a2-8a6f-51433732ab26= %40isocpp.org.
------=_Part_1899_298338664.1488388687075-- ------=_Part_1898_289746571.1488388687074-- .