220 31223 <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0534: call/cc, type safety and exceptions Date: Tue, 28 Feb 2017 19:01:24 -0800 (PST) Lines: 154 Approved: news@gmane.org Message-ID: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6298_831946259.1488337284683" X-Trace: blaine.gmane.org 1488337288 29749 195.159.176.226 (1 Mar 2017 03:01:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 03:01:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBPT3DCQKGQEFQVJ5EQ@isocpp.org Wed Mar 01 04:01:23 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciuW0-0006yY-Od for gclcip-std-proposals@m.gmane.org; Wed, 01 Mar 2017 04:01:20 +0100 Original-Received: by mail-yw0-f197.google.com with SMTP id l138sf50277685ywc.5 for ; Tue, 28 Feb 2017 19:01:26 -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=oVn8gTwVr4QhiyrYtQq87YoW0yY/Oc4IPZPViYcU504=; b=Zmho7vxsBoP837ifwacQIAzVk41evqL8eZE3HW7FqBPb4HDBMe3/KqOjin0UTiDM66 tlZQ5SKZhYjKTISYhy+nxrRW1YKILI16BvGaeN1vGNlrGzYgwPUIaLkMX0OO8+dV+LQB uOBqooz/t0dlRDt5EFwZ/uJBqLuJigyUTjNQu2m0EGuTUBOfGgXtzBhS58+/NLFjV0Eo 3TCs5LPcb8kh1V4/6DfwuOmlQUqFNqJaWjAbb9Yz2JUXOLlMIe8F2M3vEB+4HSLpCMjX DQ1v/nQvOoXkWBMN7yt1HkAEu0a7oTogQVRkq7e6qYkfulPLmew4IvHCY4EmcpSnu7XW 8aXA== 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=oVn8gTwVr4QhiyrYtQq87YoW0yY/Oc4IPZPViYcU504=; b=KfQGu5Q+p4SfaCE9yid4ND82HPQlYAYbyEmkqCtGvL7nmxwzfvwa+EYsYQ6qRaMcHz tTZZDeY+nzB+tgewZUq4R3NxupW7tWSjBcEWEylFXiuU2IHldANaKzYK0JHE985ytB4R gJFPpRjAEm98YErct+0XsaXyGQ0Zl1b+1A4Cm3ZAmPqzHJNsK0Y/0CUO30GJjaeHwGV2 A6w1WcVUpue3KINS5hJ7MAB30GsRdr4tV1Wi1p2iQ8hVN99wQJGPBCoq2PionuQIb8/0 uQRua5sT/bhz9fYXysSZc+aGlXkI/NipuHYkWuHN2hTLLpteeG0/kzsHSkRdk17S0fMo SeKg== 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=oVn8gTwVr4QhiyrYtQq87YoW0yY/Oc4IPZPViYcU504=; b=DBvzEyptgIJRLaB9I0tuuf6PRxpZEdEmuHAT+NMbVRJenvW50T75V1iEBttM9hOXCB zUZ4bD6hMKDVInL634idJkl9GYVMTP0fvFuCPxF0cKpp4GlfKS12aXadPefP4FKJPjPh 1ZQIGTZWJju3LCrojvfD+Hbq91OASYhSFmXer/kEdsvDO87Ob4A6R5p+Oxlrac8D5z9q nKLxME1R63dfsGUgvN+47HITdK9qRQEQGsW2xFZQLpDhoCJ97cDoBFSpjnoXdMhqOb+r iViMvN66id7ZLlWiKe/vCwH1vJRn4xYs8NprAmVGQyCm62F/kQ1yobcCPWVr1VuCTnUW GaaA== X-Gm-Message-State: AMke39l1mQWQbOx0lyGv1JHcl9JEHtWmIk3TsnO/m08KV2NurTjud9iQWqZKbj3tc1moMQ== X-Received: by 10.129.79.19 with SMTP id d19mr1928104ywb.19.1488337286394; Tue, 28 Feb 2017 19:01:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.13.110 with SMTP id 101ls2954945oti.43.gmail; Tue, 28 Feb 2017 19:01:25 -0800 (PST) X-Received: by 10.157.82.72 with SMTP id q8mr643489otg.4.1488337285511; Tue, 28 Feb 2017 19:01:25 -0800 (PST) In-Reply-To: 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:31223 Archived-At: ------=_Part_6298_831946259.1488337284683 Content-Type: multipart/alternative; boundary="----=_Part_6299_1959364858.1488337284683" ------=_Part_6299_1959364858.1488337284683 Content-Type: text/plain; charset=UTF-8 On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote: > > Hello, > > I have some questions about call/cc in proposed implementation > > I think possibility put any arguments in continuation and access to them > through template function it is lack of type safety, and isn't good idea to > propose it in standard. > Why not specialize continuation with type of input and type of output? > Because: 1) That would limit what you can do with continuations. As currently proposed, you can pass different parameters to different parts of continuations. Your idea fixes the interface at call/cc time. 2) P0534 is intended to be as low level as possible while still being functional. By specializing types, it would be higher level than strictly *necessary*. And forward arguments of operator() to constructor of input type. > I rewrote continuation based on boost.context implementation. > Also I get rid of data_available/get_data... why not use optional? > Use `optional` to do what? To take up more space? To force me to copy values when I don't have to? What do you think about it? > > https://gist.github.com/cNoNim/bb24a613406de30d2c856bc7df1ab424 > > Also I don't understand why: > >> If an uncaught exception escapes from the entry-function, std::terminate >> is called. >> > > We can catch exception in `run` function of `record` and rethrow in > `context_exit` > Again, this would make P0534 higher level than strictly needed. If you want to provide such wrappers, that's great (and welcome). But the low-level tool shouldn't have those. As I have argued in other threads, I think it is vital to have both low-level tools and high-level tools available. For those who need the greater control, they can have that. But we should also ship with safer mechanisms that handle such things adequately. And standardizing them means that they can be inter-operable. https://gist.github.com/cNoNim/933978b23ccc13746ffe4f21de187ecd > > Sorry for custom naming convention. > -- 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/3a57e294-7254-4358-828d-c9f7757f5295%40isocpp.org. ------=_Part_6299_1959364858.1488337284683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5,= Oleg Ageev wrote:
Hello,

I have some questions about call/cc in proposed implemen= tation

I think possibility put any arguments in continuation and acc= ess to them through template function it is lack of type safety, and isn= 9;t good idea to propose it in standard.
Why not specialize continuation= with type of input and type of output?

Beca= use:

1) That would limit what you can do with continuations. As curr= ently proposed, you can pass different parameters to different parts of con= tinuations. Your idea fixes the interface at call/cc time.

2) P0534 = is intended to be as low level as possible while still being functional. By= specializing types, it would be higher level than strictly necessary.

And forward arguments of operator() to constructor of input type.
I r= ewrote continuation based on boost.context implementation.
Also I get ri= d of data_available/get_data... why not use optional?

Use `optional` to do what? To take up more space? To force me to = copy values when I don't have to?

What do you think about it?

https://gist.github.com/cNoNim/bb= 24a613406de30d2c856bc7df1ab424

Also I don't understand = why:
If an uncaught ex= ception escapes from the entry-function, std::terminate is called.

We can catch exception in `run` function of `record` and r= ethrow in `context_exit`

Again, this w= ould make P0534 higher level than strictly needed. If you want to provide s= uch wrappers, that's great (and welcome). But the low-level tool should= n't have those.

As I have argued in other threads, I think it is= vital to have both low-level tools and high-level tools available. For tho= se who need the greater control, they can have that. But we should also shi= p with safer mechanisms that handle such things adequately. And standardizi= ng them means that they can be inter-operable.

--
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/3a57e294-7254-4358-828d-c9f7757f5295= %40isocpp.org.
------=_Part_6299_1959364858.1488337284683-- ------=_Part_6298_831946259.1488337284683-- .