<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-02-21 1:21 GMT+03:00 Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Thanks for the links. I scanned through them somewhat quickly and didn’t see anything that specifically said `Never` should conform to all protocols. Did you see that specifically? I only saw mentions of it being a bottom type and therefore a subtype of all types, which I think is a bit different.</div><div><br></div><div>I think a big part of the confusion here revolves around the distinction between a type `T` being a subtype of another type `U` and `Type<T>` being a subtype of `Type<U>` (using the syntax in your metatype refactoring proposal). I’m not an expert in this area, but I suspect that `Never` can be a subtype of all existential types but without requiring it to actually *conform* to all protocols. Any non-instance protocol requirements are not available on existentials (afaik).</div></div></div></blockquote><div> </div><div>I didn't fully understand about metatypes, but otherwise yes indeed.</div><div><br></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"><div>Yes, I understood the example and it’s a good one. What I’m wondering is what benefit you actually get from this. There are two places where this default initializer could be used:</div><div><br></div><div>1. In `seq` itself. But it seems highly dubious to throw an error you know nothing about. Why does `seq` need the ability to construct an error of the same type as a function given to it without knowing anything more about that error type. Is there a use case for this?</div><div>2. In callers of `seq`. Why would the caller care if the error type that `seq` can throw has a default initializer? Is there a use case for this?</div><div><br></div><div>In other words, why do you want to specify that the type of error that might be thrown must have a default initializer? I can’t think of any possible circumstance where this would be valuable.</div><div><br></div><div>The same question can be asked of any other static requirements. What are the use cases? These seem highly theoretical to me. Maybe I’m missing something, but if so I would like to see an example of how it is *used*, not just how you would need to write an extra overload without `rethrows`.</div></div></blockquote><div><br></div><div>Seems highly theoretical to me as well.</div><div><br></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"><div>There is a potentially more practical benefit of keeping rethrows. If a function is declared with `rethrows` we know that the function itself does not throw. It only throws if one of its arguments throw when it invokes them. This is a subtle but important difference. For example, users calling a rethrowing function know that *they* have control over whether or not the call *actually* throws. The caller might pass a couple of functions that *can* throw but in this particular case are known not to throw. That could influence how the caller handles errors in the surrounding scope.</div></div></blockquote></div><br></div><div class="gmail_extra">Agreed. Now I lean towards leaving the proposal as is.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-21 1:21 GMT+03:00 Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 20, 2017, at 11:14 AM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>> wrote:</div><br class="m_-3978293884672421488Apple-interchange-newline"><div><div dir="ltr"><div class="m_-3978293884672421488markdown-here-wrapper"><p style="margin:0px 0px 1.2em!important">2017-02-20 18:23 GMT+03:00 Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>>:</p><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><div class="m_-3978293884672421488markdown-here-exclude"><div><br class="m_-3978293884672421488webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="m_-3978293884672421488gmail-"><blockquote type="cite"><div>On Feb 20, 2017, at 3:58 AM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>> wrote:</div><div><div dir="ltr"><div class="m_-3978293884672421488gmail-m_-1259088571132064262markdown-here-wrapper"><p style="margin:0px 0px 1.2em">But that raises another concern. In a previous discussion, it was taken for granted that <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">Never</code> should conform to all protocols</p></div></div></div></blockquote></span><div>Do you have a pointer to this discussion? I must have missed it.</div></div></div></blockquote><div><br class="m_-3978293884672421488webkit-block-placeholder"></div></div><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><p style="margin:0px 0px 1.2em!important"><a href="http://discourse.natecook.com/t/idea-change-noreturn-func-f-to-func-f-noreturn/1000" target="_blank">Here</a> is the discussion where the idea of “empty” type originated.<br>Some messages on the topic ended up being <a href="http://discourse.natecook.com/t/idea-repurpose-void/1406" target="_blank">there</a>.</p><p style="margin:0px 0px 1.2em!important"><a href="http://discourse.natecook.com/t/idea-repurpose-void/1406" target="_blank">This</a> is the earliest mention of usage of this empty type for <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">rethrows</code> I could find.<br>Some related messages are <a href="http://discourse.natecook.com/t/draft-change-noreturn-to-unconstructible-return-type/1765/16" target="_blank">here</a> as well.</p><div><br></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="m_-3978293884672421488markdown-here-wrapper"><p style="margin:0px 0px 1.2em!important">We called this type <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">NoReturn</code> and meant it to be the <em>bottom type</em>, i.e. subtype of all types, meaning that if you have an instance of <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">NoReturn</code>—which can only happen in unreachable sections of code—then you can convert it to any type. It should have worked like this:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><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;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">func fatalError() -> Never
func divide(a: Int, b: Int) -> Int {
if b == 0 {
let n: Never = fatalError()
return n as Int
}
return a / b
}
</code></pre><p style="margin:0px 0px 1.2em!important">I pushed the idea of replacing <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">rethrows</code> with <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">Never</code>, inspired by Haskell. Although Haskell doesn’t have static function requirements and initializer requirements.</p><div><br></div></div></div></div></blockquote><div><br></div></span><div>Thanks for the links. I scanned through them somewhat quickly and didn’t see anything that specifically said `Never` should conform to all protocols. Did you see that specifically? I only saw mentions of it being a bottom type and therefore a subtype of all types, which I think is a bit different.</div><div><br></div><div>I think a big part of the confusion here revolves around the distinction between a type `T` being a subtype of another type `U` and `Type<T>` being a subtype of `Type<U>` (using the syntax in your metatype refactoring proposal). I’m not an expert in this area, but I suspect that `Never` can be a subtype of all existential types but without requiring it to actually *conform* to all protocols. Any non-instance protocol requirements are not available on existentials (afaik).</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="m_-3978293884672421488markdown-here-wrapper"><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><div class="m_-3978293884672421488markdown-here-exclude"><div><br class="m_-3978293884672421488webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_-3978293884672421488gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="m_-3978293884672421488gmail-m_-1259088571132064262markdown-here-wrapper"><p style="margin:0px 0px 1.2em">, because if one obtains an instance of <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">Never</code> (and they won’t), then everything is possible. But now we say that <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">Never</code> can’t conform to <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">Default</code>, because this would break its very invariant. Also it can’t conform to any protocol with static members or initializers.</p></div></div></div></blockquote></span><div>It seems highly problematic to me to say that never conforms to any protocol with non-instance requirements.</div></div></div></blockquote><div><br class="m_-3978293884672421488webkit-block-placeholder"></div></div><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><p style="margin:0px 0px 1.2em!important">Here is an example with instance requirements only:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><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;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">protocol MakesPizza {
func cook() -> Pizza
}
extension Never : MakesPizza {
func cook() -> Pizza {
// this method will never be called anyway
burnThisComputer()
}
}
let maestroLaPizza = isHeAtWork ? validMaestro : (fatalError("something went wrong") as MakesPizza)
maestroLaPizza.cook()
</code></pre><p style="margin:0px 0px 1.2em!important">In this way, <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">Never</code> can conform to any protocol with only instance requirements.</p></div></div></div></blockquote></span><div>Sure.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="m_-3978293884672421488markdown-here-wrapper"><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><div class="m_-3978293884672421488markdown-here-exclude"><div><br class="m_-3978293884672421488webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_-3978293884672421488gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="m_-3978293884672421488gmail-m_-1259088571132064262markdown-here-wrapper"><p style="margin:0px 0px 1.2em">But then basically, <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">Never</code> trick can’t be used when we request anything more than <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">Error</code> from generic error type (with static members or initializers). So this approach turns out to be more limiting than <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">rethrows</code>.<br></p></div></div></div></blockquote></span><div>Can you elaborate here? If you require a function to throw an error type that has non-instance requirements then you would necessarily be restricting callers to provide a throwing function. It is not possible to express such a function with `rethrows`. You can’t talk about the error type at all. If you could talk about the error type and were able to constrain it in this way `rethrows` would necessarily have to exhibit the same behavior as the generic version. The behavior arises out of the constraint you are applying, not the mechanism by which you forward the type.</div></div></div></blockquote><div><br class="m_-3978293884672421488webkit-block-placeholder"></div></div><div style="margin:0px 0px 1.2em!important"><br class="m_-3978293884672421488webkit-block-placeholder"></div><p style="margin:0px 0px 1.2em!important">With <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">rethrows</code> approach:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><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;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">protocol BaseError : Error {
init()
}
func seq<E1, E2>(f: () throws(E1) -> (), g: () throws(E2) -> ()) rethrows(BaseError)
where E1: BaseError, E2: BaseError { ... }
</code></pre><p style="margin:0px 0px 1.2em!important">With <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">Never</code> approach, we have to create two separate functions for the same effect, because <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">Never</code> does not fit in <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">BaseError</code>:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><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;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">func seq<E1, E2>(f: () throws(E1) -> (), g: () throws(E2) -> ()) throws(BaseError)
where E1: BaseError, E2: BaseError {
// It never actually throws E1() or E2() itself, but this fact can't be reflected in the signature
}
func seq(f: () -> (), g: () -> ()) {
// repeat the body
}
</code></pre><p style="margin:0px 0px 1.2em!important">That’s where loss of information (which I meantioned earlier) hurts: we can’t apply magic and say “if <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">E1</code> and <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">E2</code> are <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">Never</code> then <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">seq</code> does not throw. Because it <strong>can</strong> throw anyway.</p><p style="margin:0px 0px 1.2em!important">Well, I’m just repeating myself, at least I gave a bit more complete example :)</p>
<div title="MDH:PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE3LTAy
LTIwIDE4OjIzIEdNVCswMzowMCBNYXR0aGV3IEpvaG5zb24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8
YSBocmVmPSJtYWlsdG86bWF0dGhld0BhbmFuZGFiaXRzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h
dHRoZXdAYW5hbmRhYml0cy5jb208L2E+Jmd0Ozwvc3Bhbj46PGJyPjxibG9ja3F1b3RlIGNsYXNz
PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1s
ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPjxk
aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsiPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJn
bWFpbC0iPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gRmViIDIwLCAyMDE3LCBhdCAz
OjU4IEFNLCBBbnRvbiBaaGlsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbnRvbnl6aGlsaW5AZ21h
aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW50b255emhpbGluQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjwvZGl2PjxkaXY+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWwtbV8tMTI1OTA4
ODU3MTEzMjA2NDI2Mm1hcmtkb3duLWhlcmUtd3JhcHBlciI+PHAgc3R5bGU9Im1hcmdpbjogMHB4
IDBweCAxLjJlbTsiPkJ1dCB0aGF0IHJhaXNlcyBhbm90aGVyIGNvbmNlcm4uIEluIGEgcHJldmlv
dXMgZGlzY3Vzc2lvbiwgaXQgd2FzIHRha2VuIGZvciBncmFudGVkIHRoYXQgPGNvZGUgc3R5bGU9
ImZvbnQtc2l6ZTogMC44NWVtOyBmb250LWZhbWlseTogY29uc29sYXMsIGluY29uc29sYXRhLCBj
b3VyaWVyLCBtb25vc3BhY2U7IG1hcmdpbjogMHB4IDAuMTVlbTsgcGFkZGluZzogMHB4IDAuM2Vt
OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IGJvcmRlcjogMXB4IHNvbGlkIHJnYigyMzQsIDIzNCwg
MjM0KTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0OCwgMjQ4LCAyNDgpOyBib3JkZXItcmFkaXVz
OiAzcHg7IGRpc3BsYXk6IGlubGluZTsiPk5ldmVyPC9jb2RlPiBzaG91bGQgY29uZm9ybSB0byBh
bGwgcHJvdG9jb2xzPC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L3NwYW4+PGRp
dj5EbyB5b3UgaGF2ZSBhIHBvaW50ZXIgdG8gdGhpcyBkaXNjdXNzaW9uPyAmbmJzcDtJIG11c3Qg
aGF2ZSBtaXNzZWQgaXQuPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv
ZGl2PjxkaXY+W0hlcmVdKGh0dHA6Ly9kaXNjb3Vyc2UubmF0ZWNvb2suY29tL3QvaWRlYS1jaGFu
Z2Utbm9yZXR1cm4tZnVuYy1mLXRvLWZ1bmMtZi1ub3JldHVybi8xMDAwKSBpcyB0aGUgZGlzY3Vz
c2lvbiB3aGVyZSB0aGUgaWRlYSBvZiAiZW1wdHkiIHR5cGUgb3JpZ2luYXRlZC48L2Rpdj48ZGl2
PlNvbWUgbWVzc2FnZXMgb24gdGhlIHRvcGljIGVuZGVkIHVwIGJlaW5nIFt0aGVyZV0oaHR0cDov
L2Rpc2NvdXJzZS5uYXRlY29vay5jb20vdC9pZGVhLXJlcHVycG9zZS12b2lkLzE0MDYpLjwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+W1RoaXNdKGh0dHA6Ly9kaXNjb3Vyc2UubmF0ZWNvb2suY29t
L3QvaWRlYS1yZXB1cnBvc2Utdm9pZC8xNDA2KSBpcyB0aGUgZWFybGllc3QgbWVudGlvbiBvZiB1
c2FnZSBvZiB0aGlzIGVtcHR5IHR5cGUgZm9yIGByZXRocm93c2AgSSBjb3VsZCBmaW5kLjxicj48
L2Rpdj48ZGl2PlNvbWUgcmVsYXRlZCBtZXNzYWdlcyBhcmUgW2hlcmVdKGh0dHA6Ly9kaXNjb3Vy
c2UubmF0ZWNvb2suY29tL3QvZHJhZnQtY2hhbmdlLW5vcmV0dXJuLXRvLXVuY29uc3RydWN0aWJs
ZS1yZXR1cm4tdHlwZS8xNzY1LzE2KSBhcyB3ZWxsLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48
ZGl2PldlIGNhbGxlZCB0aGlzIHR5cGUgYE5vUmV0dXJuYCBhbmQgbWVhbnQgaXQgdG8gYmUgdGhl
ICpib3R0b20gdHlwZSosIGkuZS4gc3VidHlwZSBvZiBhbGwgdHlwZXMsIG1lYW5pbmcgdGhhdCBp
ZiB5b3UgaGF2ZSBhbiBpbnN0YW5jZSBvZiBgTm9SZXR1cm5gLS13aGljaCBjYW4gb25seSBoYXBw
ZW4gaW4gdW5yZWFjaGFibGUgc2VjdGlvbnMgb2YgY29kZS0tdGhlbiB5b3UgY2FuIGNvbnZlcnQg
aXQgdG8gYW55IHR5cGUuIEl0IHNob3VsZCBoYXZlIHdvcmtlZCBsaWtlIHRoaXM6PC9kaXY+PGRp
dj48YnI+PC9kaXY+PGRpdj5gYGA8L2Rpdj48ZGl2PmZ1bmMgZmF0YWxFcnJvcigpIC0mZ3Q7IE5l
dmVyPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5mdW5jIGRpdmlkZShhOiBJbnQsIGI6IEludCkg
LSZndDsgSW50IHs8L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsgaWYgYiA9PSAwIHs8L2Rpdj48ZGl2
PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXQgbjogTmV2ZXIgPSBmYXRhbEVycm9yKCk8
L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXR1cm4gbiBhcyBJbnQ8L2Rp
dj48ZGl2PiZuYnNwOyAmbmJzcDsgfTwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyByZXR1cm4gYSAv
IGI8L2Rpdj48ZGl2Pn08L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBw
dXNoZWQgdGhlIGlkZWEgb2YgcmVwbGFjaW5nIGByZXRocm93c2Agd2l0aCBgTmV2ZXJgLCBpbnNw
aXJlZCBieSBIYXNrZWxsLiBBbHRob3VnaCBIYXNrZWxsIGRvZXNuJ3QgaGF2ZSBzdGF0aWMgZnVu
Y3Rpb24gcmVxdWlyZW1lbnRzIGFuZCBpbml0aWFsaXplciByZXF1aXJlbWVudHMuPC9kaXY+PGRp
dj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn
aW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw
NCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr
LXdvcmQ7Ij48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbC0iPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
PjxkaXY+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWwtbV8tMTI1OTA4ODU3MTEzMjA2
NDI2Mm1hcmtkb3duLWhlcmUtd3JhcHBlciI+PHAgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAxLjJl
bTsiPiwgYmVjYXVzZSBpZiBvbmUgb2J0YWlucyBhbiBpbnN0YW5jZSBvZiA8Y29kZSBzdHlsZT0i
Zm9udC1zaXplOiAwLjg1ZW07IGZvbnQtZmFtaWx5OiBjb25zb2xhcywgaW5jb25zb2xhdGEsIGNv
dXJpZXIsIG1vbm9zcGFjZTsgbWFyZ2luOiAwcHggMC4xNWVtOyBwYWRkaW5nOiAwcHggMC4zZW07
IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgYm9yZGVyOiAxcHggc29saWQgcmdiKDIzNCwgMjM0LCAy
MzQpOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ4LCAyNDgsIDI0OCk7IGJvcmRlci1yYWRpdXM6
IDNweDsgZGlzcGxheTogaW5saW5lOyI+TmV2ZXI8L2NvZGU+IChhbmQgdGhleSB3b27igJl0KSwg
dGhlbiBldmVyeXRoaW5nIGlzIHBvc3NpYmxlLiBCdXQgbm93IHdlIHNheSB0aGF0IDxjb2RlIHN0
eWxlPSJmb250LXNpemU6IDAuODVlbTsgZm9udC1mYW1pbHk6IGNvbnNvbGFzLCBpbmNvbnNvbGF0
YSwgY291cmllciwgbW9ub3NwYWNlOyBtYXJnaW46IDBweCAwLjE1ZW07IHBhZGRpbmc6IDBweCAw
LjNlbTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyBib3JkZXI6IDFweCBzb2xpZCByZ2IoMjM0LCAy
MzQsIDIzNCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDgsIDI0OCwgMjQ4KTsgYm9yZGVyLXJh
ZGl1czogM3B4OyBkaXNwbGF5OiBpbmxpbmU7Ij5OZXZlcjwvY29kZT4gY2Fu4oCZdCBjb25mb3Jt
IHRvIDxjb2RlIHN0eWxlPSJmb250LXNpemU6IDAuODVlbTsgZm9udC1mYW1pbHk6IGNvbnNvbGFz
LCBpbmNvbnNvbGF0YSwgY291cmllciwgbW9ub3NwYWNlOyBtYXJnaW46IDBweCAwLjE1ZW07IHBh
ZGRpbmc6IDBweCAwLjNlbTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyBib3JkZXI6IDFweCBzb2xp
ZCByZ2IoMjM0LCAyMzQsIDIzNCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDgsIDI0OCwgMjQ4
KTsgYm9yZGVyLXJhZGl1czogM3B4OyBkaXNwbGF5OiBpbmxpbmU7Ij5EZWZhdWx0PC9jb2RlPiwg
YmVjYXVzZSB0aGlzIHdvdWxkIGJyZWFrIGl0cyB2ZXJ5IGludmFyaWFudC4gQWxzbyBpdCBjYW7i
gJl0IGNvbmZvcm0gdG8gYW55IHByb3RvY29sIHdpdGggc3RhdGljIG1lbWJlcnMgb3IgaW5pdGlh
bGl6ZXJzLjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9zcGFuPjxkaXY+SXQg
c2VlbXMgaGlnaGx5IHByb2JsZW1hdGljIHRvIG1lIHRvIHNheSB0aGF0IG5ldmVyIGNvbmZvcm1z
IHRvIGFueSBwcm90b2NvbCB3aXRoIG5vbi1pbnN0YW5jZSByZXF1aXJlbWVudHMuPC9kaXY+PC9k
aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SGVyZSBpcyBhbiBleGFt
cGxlIHdpdGggaW5zdGFuY2UgcmVxdWlyZW1lbnRzIG9ubHk6PC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj5gYGA8L2Rpdj48ZGl2PnByb3RvY29sIE1ha2VzUGl6emEgezwvZGl2PjxkaXY+Jm5ic3A7
ICZuYnNwOyBmdW5jIGNvb2soKSAtJmd0OyBQaXp6YTwvZGl2PjxkaXY+fTwvZGl2PjxkaXY+ZXh0
ZW5zaW9uIE5ldmVyIDogTWFrZXNQaXp6YSB7PC9kaXY+PGRpdj4mbmJzcDsgJm5ic3A7IGZ1bmMg
Y29vaygpIC0mZ3Q7IFBpenphIHs8L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAvLyB0aGlzIG1ldGhvZCB3aWxsIG5ldmVyIGJlIGNhbGxlZCBhbnl3YXk8L2Rpdj48ZGl2PiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBidXJuVGhpc0NvbXB1dGVyKCk8L2Rpdj48ZGl2PiZu
YnNwOyAmbmJzcDsgfTwvZGl2PjxkaXY+fTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+bGV0IG1h
ZXN0cm9MYVBpenphID0gaXNIZUF0V29yayA/IHZhbGlkTWFlc3RybyA6IChmYXRhbEVycm9yKCJz
b21ldGhpbmcgd2VudCB3cm9uZyIpIGFzIE1ha2VzUGl6emEpPC9kaXY+PGRpdj5tYWVzdHJvTGFQ
aXp6YS5jb29rKCk8L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SW4gdGhp
cyB3YXksIGBOZXZlcmAgY2FuIGNvbmZvcm0gdG8gYW55IHByb3RvY29sIHdpdGggb25seSBpbnN0
YW5jZSByZXF1aXJlbWVudHMuPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz
dHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCBy
Z2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdiBzdHlsZT0id29yZC13
cmFwOiBicmVhay13b3JkOyI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWwtIj48YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsLW1fLTEyNTkw
ODg1NzExMzIwNjQyNjJtYXJrZG93bi1oZXJlLXdyYXBwZXIiPjxwIHN0eWxlPSJtYXJnaW46IDBw
eCAwcHggMS4yZW07Ij5CdXQgdGhlbiBiYXNpY2FsbHksIDxjb2RlIHN0eWxlPSJmb250LXNpemU6
IDAuODVlbTsgZm9udC1mYW1pbHk6IGNvbnNvbGFzLCBpbmNvbnNvbGF0YSwgY291cmllciwgbW9u
b3NwYWNlOyBtYXJnaW46IDBweCAwLjE1ZW07IHBhZGRpbmc6IDBweCAwLjNlbTsgd2hpdGUtc3Bh
Y2U6IHByZS13cmFwOyBib3JkZXI6IDFweCBzb2xpZCByZ2IoMjM0LCAyMzQsIDIzNCk7IGJhY2tn
cm91bmQtY29sb3I6IHJnYigyNDgsIDI0OCwgMjQ4KTsgYm9yZGVyLXJhZGl1czogM3B4OyBkaXNw
bGF5OiBpbmxpbmU7Ij5OZXZlcjwvY29kZT4gdHJpY2sgY2Fu4oCZdCBiZSB1c2VkIHdoZW4gd2Ug
cmVxdWVzdCBhbnl0aGluZyBtb3JlIHRoYW4gPGNvZGUgc3R5bGU9ImZvbnQtc2l6ZTogMC44NWVt
OyBmb250LWZhbWlseTogY29uc29sYXMsIGluY29uc29sYXRhLCBjb3VyaWVyLCBtb25vc3BhY2U7
IG1hcmdpbjogMHB4IDAuMTVlbTsgcGFkZGluZzogMHB4IDAuM2VtOyB3aGl0ZS1zcGFjZTogcHJl
LXdyYXA7IGJvcmRlcjogMXB4IHNvbGlkIHJnYigyMzQsIDIzNCwgMjM0KTsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI0OCwgMjQ4LCAyNDgpOyBib3JkZXItcmFkaXVzOiAzcHg7IGRpc3BsYXk6IGlu
bGluZTsiPkVycm9yPC9jb2RlPiBmcm9tIGdlbmVyaWMgZXJyb3IgdHlwZSAod2l0aCBzdGF0aWMg
bWVtYmVycyBvciBpbml0aWFsaXplcnMpLiBTbyB0aGlzIGFwcHJvYWNoIHR1cm5zIG91dCB0byBi
ZSBtb3JlIGxpbWl0aW5nIHRoYW4gPGNvZGUgc3R5bGU9ImZvbnQtc2l6ZTogMC44NWVtOyBmb250
LWZhbWlseTogY29uc29sYXMsIGluY29uc29sYXRhLCBjb3VyaWVyLCBtb25vc3BhY2U7IG1hcmdp
bjogMHB4IDAuMTVlbTsgcGFkZGluZzogMHB4IDAuM2VtOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7
IGJvcmRlcjogMXB4IHNvbGlkIHJnYigyMzQsIDIzNCwgMjM0KTsgYmFja2dyb3VuZC1jb2xvcjog
cmdiKDI0OCwgMjQ4LCAyNDgpOyBib3JkZXItcmFkaXVzOiAzcHg7IGRpc3BsYXk6IGlubGluZTsi
PnJldGhyb3dzPC9jb2RlPi48YnI+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48
L3NwYW4+PGRpdj5DYW4geW91IGVsYWJvcmF0ZSBoZXJlPyAmbmJzcDtJZiB5b3UgcmVxdWlyZSBh
IGZ1bmN0aW9uIHRvIHRocm93IGFuIGVycm9yIHR5cGUgdGhhdCBoYXMgbm9uLWluc3RhbmNlIHJl
cXVpcmVtZW50cyB0aGVuIHlvdSB3b3VsZCBuZWNlc3NhcmlseSBiZSByZXN0cmljdGluZyBjYWxs
ZXJzIHRvIHByb3ZpZGUgYSB0aHJvd2luZyBmdW5jdGlvbi4gJm5ic3A7SXQgaXMgbm90IHBvc3Np
YmxlIHRvIGV4cHJlc3Mgc3VjaCBhIGZ1bmN0aW9uIHdpdGggYHJldGhyb3dzYC4gJm5ic3A7WW91
IGNhbuKAmXQgdGFsayBhYm91dCB0aGUgZXJyb3IgdHlwZSBhdCBhbGwuICZuYnNwO0lmIHlvdSBj
b3VsZCB0YWxrIGFib3V0IHRoZSBlcnJvciB0eXBlIGFuZCB3ZXJlIGFibGUgdG8gY29uc3RyYWlu
IGl0IGluIHRoaXMgd2F5IGByZXRocm93c2Agd291bGQgbmVjZXNzYXJpbHkgaGF2ZSB0byBleGhp
Yml0IHRoZSBzYW1lIGJlaGF2aW9yIGFzIHRoZSBnZW5lcmljIHZlcnNpb24uICZuYnNwO1RoZSBi
ZWhhdmlvciBhcmlzZXMgb3V0IG9mIHRoZSBjb25zdHJhaW50IHlvdSBhcmUgYXBwbHlpbmcsIG5v
dCB0aGUgbWVjaGFuaXNtIGJ5IHdoaWNoIHlvdSBmb3J3YXJkIHRoZSB0eXBlLjwvZGl2PjwvZGl2
PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PldpdGggYHJldGhyb3dzYCBh
cHByb2FjaDo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+cHJvdG9jb2wg
QmFzZUVycm9yIDogRXJyb3IgezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyBpbml0KCk8L2Rpdj48
ZGl2Pn08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmZ1bmMgc2VxJmx0O0UxLCBFMiZndDsoZjog
KCkgdGhyb3dzKEUxKSAtJmd0OyAoKSwgZzogKCkgdGhyb3dzKEUyKSAtJmd0OyAoKSkgcmV0aHJv
d3MoQmFzZUVycm9yKTwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZSBFMTogQmFz
ZUVycm9yLCBFMjogQmFzZUVycm9yIHsgLi4uIH08L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+V2l0aCBgTmV2ZXJgIGFwcHJvYWNoLCB3ZSBoYXZlIHRvIGNyZWF0ZSB0d28g
c2VwYXJhdGUgZnVuY3Rpb25zIGZvciB0aGUgc2FtZSBlZmZlY3QsIGJlY2F1c2UgYE5ldmVyYCBk
b2VzIG5vdCBmaXQgaW4gYEJhc2VFcnJvcmA6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5gYGA8
L2Rpdj48ZGl2PjxkaXY+ZnVuYyBzZXEmbHQ7RTEsIEUyJmd0OyhmOiAoKSB0aHJvd3MoRTEpIC0m
Z3Q7ICgpLCBnOiAoKSB0aHJvd3MoRTIpIC0mZ3Q7ICgpKSB0aHJvd3MoQmFzZUVycm9yKTwvZGl2
PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZSBFMTogQmFzZUVycm9yLCBFMjogQmFzZUVy
cm9yIHs8L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsgLy8gSXQgbmV2ZXIgYWN0dWFsbHkgdGhyb3dz
IEUxKCkgb3IgRTIoKSBpdHNlbGYsIGJ1dCB0aGlzIGZhY3QgY2FuJ3QgYmUgcmVmbGVjdGVkIGlu
IHRoZSBzaWduYXR1cmU8L2Rpdj48ZGl2Pn08L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2
PjxkaXY+ZnVuYyBzZXEoZjogKCkgLSZndDsgKCksIGc6ICgpIC0mZ3Q7ICgpKSB7PC9kaXY+PGRp
dj4mbmJzcDsgJm5ic3A7IC8vIHJlcGVhdCB0aGUgYm9keTwvZGl2PjxkaXY+fTwvZGl2PjwvZGl2
PjxkaXY+YGBgPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGF0J3Mgd2hlcmUgbG9zcyBvZiBp
bmZvcm1hdGlvbiAod2hpY2ggSSBtZWFudGlvbmVkIGVhcmxpZXIpIGh1cnRzOiB3ZSBjYW4ndCBh
cHBseSBtYWdpYyBhbmQgc2F5ICJpZiBgRTFgIGFuZCBgRTJgIGFyZSBgTmV2ZXJgIHRoZW4gYHNl
cWAgZG9lcyBub3QgdGhyb3cuIEJlY2F1c2UgaXQgKipjYW4qKiB0aHJvdyBhbnl3YXkuPC9kaXY+
PGRpdj48YnI+PC9kaXY+PGRpdj5XZWxsLCBJJ20ganVzdCByZXBlYXRpbmcgbXlzZWxmLCBhdCBs
ZWFzdCBJIGdhdmUgYSBiaXQgbW9yZSBjb21wbGV0ZSBleGFtcGxlIDopPC9kaXY+PC9kaXY+PC9k
aXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div>
</div></blockquote></span></div><br><div>Yes, I understood the example and it’s a good one. What I’m wondering is what benefit you actually get from this. There are two places where this default initializer could be used:</div><div><br></div><div>1. In `seq` itself. But it seems highly dubious to throw an error you know nothing about. Why does `seq` need the ability to construct an error of the same type as a function given to it without knowing anything more about that error type. Is there a use case for this?</div><div>2. In callers of `seq`. Why would the caller care if the error type that `seq` can throw has a default initializer? Is there a use case for this?</div><div><br></div><div>In other words, why do you want to specify that the type of error that might be thrown must have a default initializer? I can’t think of any possible circumstance where this would be valuable.</div><div><br></div><div>The same question can be asked of any other static requirements. What are the use cases? These seem highly theoretical to me. Maybe I’m missing something, but if so I would like to see an example of how it is *used*, not just how you would need to write an extra overload without `rethrows`.</div><div><br></div><div>There is a potentially more practical benefit of keeping rethrows. If a function is declared with `rethrows` we know that the function itself does not throw. It only throws if one of its arguments throw when it invokes them. This is a subtle but important difference. For example, users calling a rethrowing function know that *they* have control over whether or not the call *actually* throws. The caller might pass a couple of functions that *can* throw but in this particular case are known not to throw. That could influence how the caller handles errors in the surrounding scope.</div><div><br></div><div><br></div><div><br></div><div><br></div></div></blockquote></div><br></div>