220 31267 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: Wed, 1 Mar 2017 12:22:01 -0800 (PST) Lines: 180 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_1979_805564204.1488399721170" X-Trace: blaine.gmane.org 1488399723 7701 195.159.176.226 (1 Mar 2017 20:22:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 20:22:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2W23TCQKGQEVJA2EXY@isocpp.org Wed Mar 01 21:21:58 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjAl3-0001R7-Ll for gclcip-std-proposals@m.gmane.org; Wed, 01 Mar 2017 21:21:58 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id n89sf58953378pfa.7 for ; Wed, 01 Mar 2017 12:22:03 -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=mPH7oHf2aJOiYKnhH8WDorP+pB7E5NN//8S+wRay36o=; b=05qiwFt2v7n1CA4DmOGNJcuz7ew0dfHyZycGNFsQ1Y22JLi+/Li9WMmOxa+VDSoSX9 L27JYbQkbm7pk9JOlTJpddVJWRDeutaCFAMr2VHcp/I9t85tVbHqGc2s1u6Jgk2EQHjW catmKbm6agYWwSBKkoFr9a1zC+3l0YargI8lW2DfZAL/xotWzNXjLDrsVTZEQSXKgV5s VSouWAUuJhLBT1Rv/k6DWPD+SPmdjlzyuvFaZ0VP+4rh5CnJxecnf+2QAOjce7MI3TX4 kDxpa4ROr5w9OvTKoM9SY+00Z5vlgEaxBQ3Q6fGbqlAZn9TipL+qVs7NW1WmSHpiA4TN H//Q== 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=mPH7oHf2aJOiYKnhH8WDorP+pB7E5NN//8S+wRay36o=; b=qcKDybwxRkwpjcPeSWNuS/xf+H8aM7FwgnHjPrrkKvNwCI6VcRSE3wq+o1GaW2Txrr qcgnvv7YfxJFOy2ra820IvY0+BxELMUhQRTpMRJsT9oYIS5d8RE9Blkj7hDjkmTPtjK+ Iqo0Kc5WWozNkQyQxJXxN2+mJ2je3sLzyC+tL4loyH4kYSOrzeEtxkRPnKCvWn0fKMky VVMQoBV2w+6MA/OTewij7rZAYDDv2dOm/cUwpl/ywpFAVSbJV82E/0aMxUSFCbVGAri+ NEfaPaaQzHBikCSB83RdU2Qc0ho2admdXYJZ3hW6hxNpFw+dKkU0/2yWslvz6yMa/udn f4pQ== 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=mPH7oHf2aJOiYKnhH8WDorP+pB7E5NN//8S+wRay36o=; b=qmPnFJ6i5I2KHNp5iUwf6pukKFKVHRI4Miqpvjlj9qlLt1PrXhaIOPpUBIYqCjteWM u6N/BqGA10VgfD+c5mECVluHNuT9GbQBct/a2I/b51RGJwPC581W3+6oOhV2uP9tKl/l tOdMw3/l5yq5Je6QsNmOllh/6wzTLHDrXdOySjuAMCfUx17NYz7dbFxir4x0GXWb8nVd cqI0pOe7CGI45sOEOjfgzhaupb1hpR1QNOc6e4kHOqsTfReEkN9cSAceDb7QJ525d21L 8CjfmIiuAhrDaz+igeq4znftUHxCvULlXFLxW07NXIsTIObMpePT44+rXN0yNT4ZTXHo jhAw== X-Gm-Message-State: AMke39maYrmj4sleXJy01ZYliulYVeXrgvHO6bDl6fE/oc0iDrFWWHNvhXFO9RV7DzjK+A== X-Received: by 10.99.119.78 with SMTP id s75mr3685984pgc.124.1488399722968; Wed, 01 Mar 2017 12:22:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.240 with SMTP id g103ls4890085otg.39.gmail; Wed, 01 Mar 2017 12:22:02 -0800 (PST) X-Received: by 10.157.67.140 with SMTP id t12mr1317243ote.7.1488399722011; Wed, 01 Mar 2017 12:22:02 -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:31267 Archived-At: ------=_Part_1979_805564204.1488399721170 Content-Type: multipart/alternative; boundary="----=_Part_1980_941472134.1488399721170" ------=_Part_1980_941472134.1488399721170 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 1, 2017 at 12:18:07 PM UTC-5, Giovanni Piero Deretta wrote: > > 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). > Static checking between the parameters to `callcc` and the parameters to the function being invoked is one thing. But static checking between the parameters to `continuation::operator()` and to the receiving code is quite something else. It is perfectly reasonable to initiate a `callcc` with one set of parameters, but provide different parameters of different types at continuation time. Also, it's important to recognize that the function which began the `callcc` operation may be doing generic boilerplate stuff: storing a promise, building a channel, etc. Its return value will in many cases be irrelevant. So it doesn't make sense to have `callcc` statically assume that the return value of that function is meaningful to the caller. The fundamental difference between `std::function` and a continuation is that the former is intended to be a go-between and the latter is not. The former is just a value type for storing and invoking any C++ callable. `callcc` has nothing to do with that; it's creating new functionality. And that new functionality has its own needs. For example, guaranteed elision should still work through a `std::function` call, for both parameters and return values. But there's no way to make it work through a continuation; there has to be a copy/move of parameters into the continuation's stack, and a copy/move of return values from the continuation's stack. So clearly, we're talking about two very different things here. -- 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/aecc5a06-78cc-4071-8cce-b2e731439463%40isocpp.org. ------=_Part_1980_941472134.1488399721170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, March 1, 2017 at 12:18:07 PM UTC-5, = Giovanni Piero Deretta wrote:
<= div dir=3D"ltr">On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas = wrote:


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

So we need the safe mech= anism, and we need it shipped with the system. But that should not be the <= i>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 sacrifice= d. So `callcc/continuation` would naturally be type-safe, with `unsafe_call= cc/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 variant w= ould simply be std::continuation<void*>, while the dynamic variant wo= uld be continuation<std::any_ptr>, given a suitable implementation of= any_ptr.

I don't think you unders= tood what I meant when I said "type safe". I specifically don&= #39;t mean that the continuation has a static and typed set of paramete= rs. What I mean is that getting the parameter back is type-checked and ther= efore safe. But it's a runtime check, not a compile-time check.<= br>
This prevents compile-time tight coupling while still having safety = on the receiving end.

Hum, but this me= ans that those that want statically check type safety (a very common use ca= se, think generators), are left in the cold and need to roll their own cont= inuation 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 i= s possible, but not desirable (incidentally Qt slot types used to be only d= ynamically checked and it was a pain). I don't see why continuation wou= ld be different (in fact there is a very strong affinity between continuati= ons and functions).

Static checking betwee= n the parameters to `callcc` and the parameters to the function being invok= ed is one thing. But static checking between the parameters to `continuatio= n::operator()` and to the receiving code is quite something else. It is per= fectly reasonable to initiate a `callcc` with one set of parameters, but pr= ovide different parameters of different types at continuation time.

= Also, it's important to recognize that the function which began the `ca= llcc` operation may be doing generic boilerplate stuff: storing a promise, = building a channel, etc. Its return value will in many cases be irrelevant.= So it doesn't make sense to have `callcc` statically assume that the r= eturn value of that function is meaningful to the caller.

The fundam= ental difference between `std::function` and a continuation is that the for= mer is intended to be a go-between and the latter is not. The former is jus= t a value type for storing and invoking any C++ callable. `callcc` has noth= ing to do with that; it's creating new functionality. And that new func= tionality has its own needs.

For example, guaranteed elision should = still work through a `std::function` call, for both parameters and return v= alues. But there's no way to make it work through a continuation; there= has to be a copy/move of parameters into the continuation's stack, and= a copy/move of return values from the continuation's stack.

So = clearly, we're talking about two very different things here.
<= /div>

--
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/aecc5a06-78cc-4071-8cce-b2e731439463= %40isocpp.org.
------=_Part_1980_941472134.1488399721170-- ------=_Part_1979_805564204.1488399721170-- .