<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="">On Dec 9, 2015, at 5:30 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">But I'm not sure if it would work well to generate this on-demand; might work better to do it at interface-generation time, along with OptionSetType conformances, etc.</div></div></div></div></div></blockquote></span></div><br class=""><div class="">I’m not sure what you mean here,</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote></div><br class=""></div><div class="gmail_extra">I'd have to look at the code before I'll be able to ask a fully coherent question (you mentioned the same place memberwise initializers are synthesized).</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I was guessing that having multiple "extension NSSortOptions : Enumerable {}" in different modules (or different files in the same module) might cause problems, so you'd have to do it only one place — i.e. NSSortOptions would either be imported as protocol<OptionSetType, Enumerable> or it wouldn't, with no way to change it post-hoc from user code.</div></div></div></blockquote><br class=""></div><div>Ah, I see what you mean. Yes, I don’t think that the memberwise initializer logic is the place to look, it is probably better to look at at the logic that synthesizes the ErrorType members, since this is currently allowed:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>enum X { case A, B }<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>extension X : ErrorType {}<br class=""><br class=""></div><div>in principle there should be no problem with multiply defined members, since they will have different module qualifications and name lookup paths.</div><div><br class=""></div><div>-Chris</div></body></html>