<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 19, 2017, at 1:32 PM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" class="">antonyzhilin@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">Now that I think about it, generic throws does not exactly cover <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">rethrows</code>.<br class="">Firstly, <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">rethrows</code> has semantic information that function itself does not throw—it would be lost.</p></div></div></div></blockquote>Can you elaborate further on what you mean by this?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">Secondly, <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">rethrows</code> allows a function with multiple throwing function parameters to become non-throwing iff all the arguments are non-throwing.<br class="">How would you express it with generics?<br class="">In the proposal, in this case you are required to provide a non-generic supertype of all used error types. This type can’t just turn into <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">Never</code> automatically.</p></div></div></div></blockquote><div>This is a very good question. I’m curious if Joe has a solution that doesn’t require introducing any additional features into Swift.</div><div><br class=""></div><div>The answer I would like to see (that won’t happen in Swift 4) is to adopt some of the ideas in my value subtyping manifesto, including structural unions (that *do not* expose any members, even if there are members that all types have in common). All you would be able to do with such a union is convert from one of its constituent types to the union type and cast back down to one of the constituent types.</div><div><br class=""></div><div>Having unions like that would very elegantly solve the problem of a function that needs to throw more than one type. It also covers the case you bring up: `Never | Never | Never` would be the exact same type as `Never`. You would never write out `Never | Never | Never` of course, but in a generic context it’s important that we be able to spell it that way and have it collapse to a simple unordered set of its constituent types.</div><div><br class=""></div><div>Use of these structural union types would be discouraged in most cases, but they would be very powerful and useful in specialized contexts. Error handling is one of those contexts. Another is at the boundary of a system when you need to accept a heterogenous collection of a small, fixed set of types (as is discussed in the thread about open and public protocols).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">One solution would be to retain <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">rethrows</code> as an additional attribute.<br class="">It would help with semantic information, and resulting error will be able to turn into <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">Never</code> as a special case—now that we know, that this function doesn’t throw that error itself.</p></div></div></div></blockquote>I'm curious to hear Joe’s thought on this. It’s possible this would be a necessary bridge solution until we have something more permanent as I described above.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">2017-02-19 0:16 GMT+03:00 Martin Waitz <<a href="mailto:tali@admingilde.org" target="_blank" class="">tali@admingilde.org</a>>:</p><div style="margin: 0px 0px 1.2em !important;" class=""><br class="webkit-block-placeholder"></div><div class="markdown-here-exclude"><div class=""><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:</div><br class="m_-5212946143225501370m_-3606562864695778611Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">Thank you for taking the time to put this proposal together Anton! I really want to see typed throws make it into Swift 4. This will be a very nice feature to have.<div class=""><br class=""></div><div class="">I noticed that you included Joe Groff’s idea of replacing `rethrows` by making every function have an error type which is by default `Never` for non-throwing functions and `Error` for throwing functions that do not specify an error type. </div><div class=""><br class=""></div><div class="">I want to urge you to consider updating the proposal to take this direction now rather than later. This is a breaking change which means the longer we wait the harder it is to justify. In fact, I think incorporating the breaking change could increase the chances of it being accepted for Swift 4. Without that it is a purely additive change and those are not being given priority in the Swift 4 release.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Seconded.</div><div class="">With typed throwing function parameters, it makes a lot of sense to be able to specify the rethrown type, based on the function given as parameter.<br class=""></div></div></div></blockquote><div class=""><br class="webkit-block-placeholder"></div></div><div style="margin: 0px 0px 1.2em !important;" class=""><br class="webkit-block-placeholder"></div>
<div title="MDH:PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5Ob3cgdGhh
dCBJIHRoaW5rIGFib3V0IGl0LCBnZW5lcmljIHRocm93cyBkb2VzIG5vdCBleGFjdGx5IGNvdmVy
IGByZXRocm93c2AuPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkZpcnN0bHksIGByZXRo
cm93c2AgaGFzIHNlbWFudGljIGluZm9ybWF0aW9uIHRoYXQgZnVuY3Rpb24gaXRzZWxmIGRvZXMg
bm90IHRocm93LS1pdCB3b3VsZCBiZSBsb3N0LjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl
Ij48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPlNlY29uZGx5LCBgcmV0aHJvd3Ng
IGFsbG93cyBhIGZ1bmN0aW9uIHdpdGggbXVsdGlwbGUgdGhyb3dpbmcgZnVuY3Rpb24gcGFyYW1l
dGVycyB0byBiZWNvbWUgbm9uLXRocm93aW5nIGlmZiBhbGwgdGhlIGFyZ3VtZW50cyBhcmUgbm9u
LXRocm93aW5nLjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5Ib3cgd291bGQgeW91IGV4
cHJlc3MgaXQgd2l0aCBnZW5lcmljcz88L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+SW4g
dGhlIHByb3Bvc2FsLCBpbiB0aGlzIGNhc2UgeW91IGFyZSByZXF1aXJlZCB0byBwcm92aWRlIGEg
bm9uLWdlbmVyaWMgc3VwZXJ0eXBlIG9mIGFsbCB1c2VkIGVycm9yIHR5cGVzLiBUaGlzIHR5cGUg
Y2FuJ3QganVzdCB0dXJuIGludG8gYE5ldmVyYCBhdXRvbWF0aWNhbGx5LjwvZGl2PjxkaXYgY2xh
c3M9ImdtYWlsX3F1b3RlIj48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uZSBz
b2x1dGlvbiB3b3VsZCBiZSB0byByZXRhaW4gYHJldGhyb3dzYCBhcyBhbiBhZGRpdGlvbmFsIGF0
dHJpYnV0ZS48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+SXQgd291bGQgaGVscCB3aXRo
IHNlbWFudGljIGluZm9ybWF0aW9uLCBhbmQgcmVzdWx0aW5nIGVycm9yIHdpbGwgYmUgYWJsZSB0
byB0dXJuIGludG8gYE5ldmVyYCBhcyBhIHNwZWNpYWwgY2FzZS0tbm93IHRoYXQgd2Uga25vdywg
dGhhdCB0aGlzIGZ1bmN0aW9uIGRvZXNuJ3QgdGhyb3cgdGhhdCBlcnJvciBpdHNlbGYuPC9kaXY+
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90
ZSI+MjAxNy0wMi0xOSAwOjE2IEdNVCswMzowMCBNYXJ0aW4gV2FpdHogPHNwYW4gZGlyPSJsdHIi
PiZsdDs8YSBocmVmPSJtYWlsdG86dGFsaUBhZG1pbmdpbGRlLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PnRhbGlAYWRtaW5naWxkZS5vcmc8L2E+Jmd0Ozwvc3Bhbj46PGJyPjxibG9ja3F1b3RlIGNsYXNz
PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj
Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13
b3JkIj48YnI+PGRpdj48c3Bhbj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PkFtIDE4LjAy
LjIwMTcgdW0gMTc6Mzcgc2NocmllYiBNYXR0aGV3IEpvaG5zb24gdmlhIHN3aWZ0LWV2b2x1dGlv
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3aWZ0LWV2b2x1dGlvbkBzd2lmdC5vcmciIHRhcmdldD0i
X2JsYW5rIj5zd2lmdC1ldm9sdXRpb25Ac3dpZnQub3JnPC9hPiZndDs6PC9kaXY+PGJyIGNsYXNz
PSJtXy01MjEyOTQ2MTQzMjI1NTAxMzcwbV8tMzYwNjU2Mjg2NDY5NTc3ODYxMUFwcGxlLWludGVy
Y2hhbmdlLW5ld2xpbmUiPjxkaXY+PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPlRo
YW5rIHlvdSBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHB1dCB0aGlzIHByb3Bvc2FsIHRvZ2V0aGVy
IEFudG9uISZuYnNwOyBJIHJlYWxseSB3YW50IHRvIHNlZSB0eXBlZCB0aHJvd3MgbWFrZSBpdCBp
bnRvIFN3aWZ0IDQuJm5ic3A7IFRoaXMgd2lsbCBiZSBhIHZlcnkgbmljZSBmZWF0dXJlIHRvIGhh
dmUuPGRpdj48YnI+PC9kaXY+PGRpdj5JIG5vdGljZWQgdGhhdCB5b3UgaW5jbHVkZWQgSm9lIEdy
b2Zm4oCZcyBpZGVhIG9mIHJlcGxhY2luZyBgcmV0aHJvd3NgIGJ5IG1ha2luZyBldmVyeSBmdW5j
dGlvbiBoYXZlIGFuIGVycm9yIHR5cGUgd2hpY2ggaXMgYnkgZGVmYXVsdCBgTmV2ZXJgIGZvciBu
b24tdGhyb3dpbmcgZnVuY3Rpb25zIGFuZCBgRXJyb3JgIGZvciB0aHJvd2luZyBmdW5jdGlvbnMg
dGhhdCBkbyBub3Qgc3BlY2lmeSBhbiBlcnJvciB0eXBlLiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2Pkkgd2FudCB0byB1cmdlIHlvdSB0byBjb25zaWRlciB1cGRhdGluZyB0aGUgcHJv
cG9zYWwgdG8gdGFrZSB0aGlzIGRpcmVjdGlvbiBub3cgcmF0aGVyIHRoYW4gbGF0ZXIuJm5ic3A7
IFRoaXMgaXMgYSBicmVha2luZyBjaGFuZ2Ugd2hpY2ggbWVhbnMgdGhlIGxvbmdlciB3ZSB3YWl0
IHRoZSBoYXJkZXIgaXQgaXMgdG8ganVzdGlmeS4mbmJzcDsgSW4gZmFjdCwgSSB0aGluayBpbmNv
cnBvcmF0aW5nIHRoZSBicmVha2luZyBjaGFuZ2UgY291bGQgaW5jcmVhc2UgdGhlIGNoYW5jZXMg
b2YgaXQgYmVpbmcgYWNjZXB0ZWQgZm9yIFN3aWZ0IDQuJm5ic3A7IFdpdGhvdXQgdGhhdCBpdCBp
cyBhIHB1cmVseSBhZGRpdGl2ZSBjaGFuZ2UgYW5kIHRob3NlIGFyZSBub3QgYmVpbmcgZ2l2ZW4g
cHJpb3JpdHkgaW4gdGhlIFN3aWZ0IDQgcmVsZWFzZS48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2Nr
cXVvdGU+PGRpdj48YnI+PC9kaXY+PC9zcGFuPjxkaXY+U2Vjb25kZWQuPC9kaXY+PGRpdj5XaXRo
IHR5cGVkIHRocm93aW5nIGZ1bmN0aW9uIHBhcmFtZXRlcnMsIGl0IG1ha2VzIGEgbG90IG9mIHNl
bnNlIHRvIGJlIGFibGUgdG8gc3BlY2lmeSB0aGUgcmV0aHJvd24gdHlwZSwgYmFzZWQgb24gdGhl
IGZ1bmN0aW9uIGdpdmVuIGFzIHBhcmFtZXRlci48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9j
a3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0" class=""></div></div></div>
</div></blockquote></div><br class=""></body></html>