<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=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class="">Changing how Objective-C initializers are imported sounds like a big and dangerous task, but factory initializers behave exactly how Objective-C initializers behave, compared to Swift initializers. Importing them all as `fatory` init wouldn't change the behavior in any way, only mark the initializer as `factory`. However, it does look like Objective-C initializers will have to be a special case, in order for non-factory initializers in Swift to be able to override them.</div></div></blockquote><br class=""></div><div class="">IIRC, there is already special logic for handling Objective-C initializers from Swift; they are effectively implemented as if they <i class="">were</i> factory initializers. I still don’t think we need to explicitly mark them as factory though, as that would certainly be confusing to newcomers (and would mess with the convenience/required initializer chain).</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class="">We could just drop factory initializers in classes for now and start by only adding them to protocols (which is incomparably easier) and see where this goes first.</div></div></blockquote><br class=""></div><div class="">I believe factory initializers are most powerful with classes, and since this would need to be solved anyway, I think we should move forward with it for all types + protocol extensions</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 12:43 AM, Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" class="">gor@gyolchanyan.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I have thought of `static init`, but there are two problems with it:<div class="">* The `static`-ness of it is purely an implementational detail and is not related to the purpose of these initializers.</div><div class="">* The term "static initializer" has another meaning in Objective-C (and other languages) that initializes the type itself once at the start of the process.</div><div class=""><br class=""></div><div class="">Changing how Objective-C initializers are imported sounds like a big and dangerous task, but factory initializers behave exactly how Objective-C initializers behave, compared to Swift initializers. Importing them all as `fatory` init wouldn't change the behavior in any way, only mark the initializer as `factory`. However, it does look like Objective-C initializers will have to be a special case, in order for non-factory initializers in Swift to be able to override them.</div><div class=""><br class=""></div><div class="">*OR*</div><div class=""><br class=""></div><div class="">The way initializers worked in Objective-C is the opposite of how they work in Swift: `self = [super init]; self.member = value;` (not counting the NULL checks). This allowed overriding them and delegating to them even though they're essentially factory methods. The problem with this was that with Objective-C's poor type safety, it was easy to forget to initialize the members, but with Swift, there's a strong type system for that. What we could do is to make Objective-C's factory initializers create the dynamic type using NSObject's `init()` and have the subclass's factory initializer initialize all its members *after" the instance is created.</div><div class=""><br class=""></div><div class="">*OR*</div><div class=""><br class=""></div><div class="">We could just drop factory initializers in classes for now and start by only adding them to protocols (which is incomparably easier) and see where this goes first.</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 12:30 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jun 11, 2017 at 3:49 PM, Riley Testut <span dir="ltr" class=""><<a href="mailto:rileytestut@gmail.com" target="_blank" class="">rileytestut@gmail.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""></div><div class="">Some thoughts on updated proposal:</div><div class=""><br class=""></div><div class="">• I strongly believe factory initializers should follow the progressive disclosure pattern, and importing all Objective-C initializers as factory initializers breaks this. While there is precedent for this because of the "open" access control, I'd prefer if maybe we compromised and any @objc initializer is assumed to have the same performance characteristics as a factory initializer, without having to prepend the factory keyword.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm not expert enough on Obj-C interop issues to make insightful comments on this, but my naive impression here is that changing how _all_ Obj-C initializers are imported by default seems...risky? Perhaps a summary of how the compiler currently handles the issue is in order for this proposal, so as to enable readers to evaluate this change.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">• While I did initially propose the factory keyword, I'm still not entirely sure "factory" is the right choice. Though if the consensus that is the right keyword, then I'll happily accept that.</div><div class="">• Having "self" refer to the dynamic <i class="">type</i> of the returned instance seems...weird. While technically correct for a static method, I'd expect self to be an instance and Self to be the dynamic type just like any other initializer.</div></div></blockquote><div class=""><br class=""></div><div class="">Agree: `self` referring to a type is unprecedented when it's not a static method--this feels weird. If this is essential for the whole design, have you considered maybe just calling it `static init`? (This raises a potentially interesting thought about whether it'd make sense to also have a `class init`...)</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">• Factory initializers should be used for <i class="">any </i>initializer that returns a value. Furthermore, I don't think we should limit factory initializers to just protocol extensions and classes. Sure it doesn't make sense for value types, but I don't think we should forbid that (and that way if you want to return a value instead of a assign to self, you'd just use factory intializer)</div><div class="">• I don't think there should be <i class="">any</i> delegating to other factory initializers. Nothing would stop you from returning a value initialized via another factory method, however.</div></div></blockquote><div class=""><br class=""></div><div class="">Hmm. That sounds workable and simpler, definitely.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">Sorry if sounds a little rambled, don't have access to a computer for the rest of the day so typing this all up on my phone! </div><div class=""><div class="h5"><div class=""><br class="">On Jun 11, 2017, at 1:39 PM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Here's the updated proposal:<div class=""><br class=""></div><div class=""><a href="https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md" target="_blank" class="">https://github.com/technogen-<wbr class="">gg/swift-evolution/blob/<wbr class="">master/proposals/NNNN-factory-<wbr class="">initializers.md</a></div><div class=""><br class=""></div><div class="">Is there anything else or are we good to go?<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 8:46 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jun 11, 2017 at 12:43 PM, Gor Gyolchanyan <span dir="ltr" class=""><<a href="mailto:gor@gyolchanyan.com" target="_blank" class="">gor@gyolchanyan.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">I have no better name besides a factory initializer for now.<div class="">I have thought about this some more and came to this conclusion about the keyword:</div><div class="">Let the keyword be universally applied to all factory initializers, to statically enforce the rules of factory initializers (see below), because the more I think of it, the more I realize that you'd generally not want to mix factory and non-factory initializers, due to their vastly differing purposes.</div><div class=""><br class=""></div><div class="">Having said that, my current understanding of this proposal is as follows:<div class=""><br class=""></div><div class="">* Allow marking initializers inside protocol extensions, class declarations and class extensions as `factory`.</div><div class="">* In initializers marked as `factory`:</div><div class=""><span class="m_1666313611408171104m_4423476558537416042Apple-tab-span" style="white-space:pre-wrap"> </span>* Change the implicit `self` parameter to mean `the dynamic type of the enclosing type` (just like it does in static methods).</div><div class=""><span class="m_1666313611408171104m_4423476558537416042Apple-tab-span" style="white-space:pre-wrap"> </span>* Disallow delegating initialization to initializers not marked as `factory`.</div><div class=""><span class="m_1666313611408171104m_4423476558537416042Apple-tab-span" style="white-space:pre-wrap"> </span>* Require terminating the initializer by either returning a compatible type (a conforming type for protocols, a derived instance for classes) or returning `nil` (if the initializer is failable).</div><div class="">* In initializers inside enum declarations, enum extensions, struct declarations and struct extensions:</div><div class=""><span class="m_1666313611408171104m_4423476558537416042Apple-tab-span" style="white-space:pre-wrap"> </span>* Allow terminating the initializer by returning an instance of the type being initialized.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Sounds reasonable to me.</div><div class=""><br class=""></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;line-break:after-white-space" class=""><div class=""><div class=""><div class="m_1666313611408171104h5"><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 7:38 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Sun, Jun 11, 2017 at 10:34 AM, Gor Gyolchanyan<span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:gor@gyolchanyan.com" target="_blank" class="">gor@gyolchanyan.c<wbr class="">om</a>></span><span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span>wrote:<br 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">I just didn't want to use the commonly proposed `factory` word, because it implies a specific semantic tied to the factory method pattern.</div><div class="">I gave it another thought and I'm thinking maybe we can forego the annotation and have the compiler deduce it automatically.</div><div class="">There are only two places where an indirect initializer can exist:</div><div class="">* Protocol extensions, returning a conforming type.</div><div class="">* Classes, returning an instance.</div><div class="">It doesn't make sense to have this on value types, since they do not have subtypes of any kind.</div><div class="">Indirect initializers are very unambiguous in protocol extensions, because the only other way of implementing an initializer in a protocol extension is via delegating initialization, so the indirect-ness of the initializer can be statically determined by whether or not there is a delegating initializer involved.</div><div class="">If the initializer in a protocol extension has a delegating initialization on any execution path, then returning an instance is disallowed and vice versa. This will ensure strict separation of initializer types for the compiler to generate code for.</div><div class="">If a failable initializer in a protocol extension unconditionally returns `nil`, then no initialization takes place anyway, so it doesn't matter, which one the compiler chooses.</div><div class="">In classes this is a bit difficult, because besides delegating initializers, they also can initialize the members directly.</div><div class="">So, in addition to the distinguishing rule for the protocol extensions, classes will also check whether any member is assigned to on any execution path.</div><div class=""><br class=""></div><div class="">What do you think?</div></div></blockquote><div class=""><br class=""></div><div class="">Keywords aren't just for the compiler; they're for the human reader too! If you believe the use of your proposed feature in protocol extensions is unambiguous to humans as well as compilers, then IMO it makes sense not to require another keyword in that place. I haven't thought deeply about whether that would be the case.</div><div class=""><br class=""></div><div class="">Clearly, you're saying that this is a more complicated situation with classes; I think it makes sense for you to consider requiring a keyword there. There is precedent for keywords modifying `init` to be required for classes but not for value types (e.g., `convenience`).</div><div class=""><br class=""></div><div class="">Regardless of whether a keyword is required or not, your feature needs a name. And here again, I think it is puzzling that you are calling them "indirect initializers" when there is already another meaning for "indirect" in Swift. Distinct concepts should have distinct names.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="m_1666313611408171104m_4423476558537416042h5"><div class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 5:53 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jun 11, 2017 at 8:49 AM, Gor Gyolchanyan<span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:gor@gyolchanyan.com" target="_blank" class="">gor@gyolchanyan.c<wbr class="">om</a>></span><span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span>wrote:<br 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Can you recall the reasons why the removal of access modifiers on extensions was rejected?</div></blockquote><div class=""><br class=""></div><div class="">It was an unassailable reason, really: people found this shorthand useful and wanted to continue to use it--it is the only way to specify that multiple members are public without explicitly labeling each one. The core team agreed it was useful.</div><div class=""><br class=""></div><div class="">My takeaway from the whole episode (I was greatly in favor of removing this shorthand, as it's highly inconsistent with all other access modifier rules) is that in general, since the bar for new syntax is so high, if a shorthand made it into the language (and especially if it's kind of an inconsistent shorthand) the general presumption must be that it is highly desired.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Also, do you think `indirect init` is confusing inside an `indirect enum`?</div></div></blockquote><div class=""><br class=""></div><div class="">I do. These are unrelated definitions of "indirect," and I'm puzzled why you'd actively choose to run into issues with the same word meaning two things when you could choose another word.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994h5"><div class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 4:40 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484Apple-interchange-newline"><div class=""><div class="">Removal of access modifiers on extensions has been proposed, reviewed, and rejected, so that’s that.</div><div class=""><br class=""></div><div class="">In general, Swift uses distinct keywords for distinct concepts, unlike Rust which likes to reuse keywords in clever ways; if you’re finding that things are getting confusing with one word meaning two things, that shouldn’t be an invitation to rip out existing syntax but is probably a good sign you shouldn’t be repurposing that keyword.</div><div class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div class="">On Sun, Jun 11, 2017 at 03:28 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_markdown"><p class="">Yeah, well I messed up my proposal from last year about removing the access modifier on extensions and wish now I wasn’t that confused back than and made it right.</p><p class="">The<span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span><code class="">indirect</code><span class="m_1666313611408171104m_4423476558537416042Apple-converted-space"> </span>keyword is literally the same story. The docs only says that this is only a shortcut.</p><blockquote class=""><p class="">„To enable indirection for all the cases of an enumeration, mark the entire enumeration with the indirect modifier—this is convenient when the enumeration contains many cases that would each need to be marked with the indirect modifier.“</p></blockquote><p class="">If you really wish to reuse that keyword here we might need to remove such shortcuts from the language (indirect enum, access modifier on extensions, anything else?).</p><div class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484webkit-block-placeholder"></div></div><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_original_html"></div></div><div style="word-wrap:break-word" class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_original_html"><div id="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><br class=""><div id="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_sign_1497168891326406912" class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_sign"><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><br class=""></div></div><div style="word-wrap:break-word" class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_original_html"><p class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178airmail_on">Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan (<a href="mailto:gor@gyolchanyan.com" target="_blank" class="">gor@gyolchanyan.com</a>) schrieb:</p><blockquote type="cite" class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178clean_bq"><span class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""></div><div class="">I always wondered, why is `indirect` allowed on the `enum` itself? Wouldn't it make more sense to apply it to individual cases that recursively refer to the `enum`?<div class="">This question also applies to access modifiers on extensions. So, what is it supposed to do? Change the default access modifier from `internal` to whatever I specify? That's just confusing, reduces readability and the syntactic gain is marginal at best.</div><div class="">If the `indirect` confusion becomes real, I'd suggest getting rid of `indirect enum` and using `indirect case` instead.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-interchange-newline"><div class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px" class="">The proposal is looking good to me. :) It will also enable easy support for custom views using XIBs in iOS development without unnecessary view nesting.</p><p style="margin:15px 0px" class="">For instance the function from this example<span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span><a href="https://stackoverflow.com/a/43123783/4572536" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://stackoverflow.<wbr class="">com/a/43123783/4572536</a><span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span>could be used directly inside an<span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">init</code>:</p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class=""><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal" class="">class MyView : UIView {
indirect init() {
return MyView.instantiateFromXib()
// Or after SR-0068
return Self.instantiateFromXib()
}
}
</code></pre><p style="margin:15px 0px" class="">There is still one little thing that bothers me, it might be a little bit confusing to have two different meanings of<span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">indirect</code><span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span>on enums.</p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class=""><code class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178swift" style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">indirect enum ArithmeticExpression {
case number(Int)
case addition(ArithmeticExpression, ArithmeticExpression)
case multiplication(ArithmeticExpre<wbr class="">ssion, ArithmeticExpression)
// This might makes no sense, but it would still be possible after
// this proposal.
indirect init(other: ArithmeticExpression) {
return other
}
// Furthermore if the keyboard is applied to the enum
// directly all other `indirect` uses are inferred.
// Will this be implicitly `indirect` because of the previous fact?
init() { … }
}
</code></pre><div style="margin:15px 0px" class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178webkit-block-placeholder"></div></div><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_original_html" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div id="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><br class=""><div id="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_sign_1497167373101756160" class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_sign"><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><br class=""><p class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178airmail_on" style="margin:15px 0px">Am 11. Juni 2017 um 00:38:56, Riley Testut via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p><blockquote type="cite" class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178clean_bq" style="margin:15px 0px"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""></div><div class=""><div class=""><span style="margin-top:0px;margin-bottom:0px" class="">Awesome! Updated my proposal to include what I believed to be the relevant portions of your indirect initializer idea. Let me know if there’s anything I missed or should change :-)</span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><a href="https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/rileytestut<wbr class="">/swift-evolution/blob/master/p<wbr class="">roposals/NNNN-factory-initiali<wbr class="">zers.md</a></span></div><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class=""><span style="margin-top:0px;margin-bottom:0px" class="">On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.com</a>> wrote:</span></div><span style="margin-top:0px;margin-bottom:0px" class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-interchange-newline"></span><div style="margin-bottom:0px" class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><span style="margin-top:0px;margin-bottom:0px" class="">Hi, Riley!</span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span></div><span style="margin-top:0px;margin-bottom:0px" class="">I think that's a great idea! We can merge the second part of my proposal (the `indirect init`) into your one and refine and consolidate the prerequisite proposal (about returning from `init` and possibly in-place member initializers) and bunch them up into a proposal cluster (the way swift coders did).</span><div class=""><span style="margin-top:0px;margin-bottom:0px" class="">Feel free to tear out any chunks from my proposal, while I think about a more in-depth rationale about revamping initialization syntax. 🙂<br class=""></span><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class=""><span style="margin-top:0px;margin-bottom:0px" class="">On Jun 10, 2017, at 8:36 PM, Riley Testut <<a href="mailto:rileytestut@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">rileytestut@gmail.com</a>> wrote:</span></div><span style="margin-top:0px;margin-bottom:0px" class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-interchange-newline"></span><div style="margin-bottom:0px" class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><span style="margin-top:0px;margin-bottom:0px" class="">Hi Gor 👋</span><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class="">I’m very much in fan of a unified initialization syntax. I submitted my own proposal for factory initializers a while back, but since it wasn’t a focus of Swift 3 or 4 I haven’t followed up on it recently. In the time since last working on it, I came to my own conclusion that rather than focusing on factory initialization, the overall initialization process should be simplified, which I’m glad to see someone else has realized as well :-)</span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class=""><br class=""></span></div><div class=""><span style="margin-top:0px;margin-bottom:0px" class="">Here’s my proposal for reference:<span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/<wbr class="">apple/swift-evolution/pull/247<wbr class="">/commits/58b5a93b322aae998eb40<wbr class="">574dee15fe54323de2e</a><span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span>Originally I used the “factory” keyword, but I think your “indirect” keyword may be a better fit (since it has precedent in the language and is not limited to “just” being about factory initialization). To divide your proposal up into smaller pieces for review, maybe we could update my proposal to use your indirect keyword, and then start a separate topic/proposal for the remaining aspects of your proposal? I agree that splitting it into smaller chunks may be better for the process.</span></div><div class=""><br class=""></div><div class="">Let me know what you think!</div><div class=""><br class=""></div><div class="">Riley</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">This is a very interesting read.</div><div class=""><br class=""></div></div></div></div></blockquote></div><div class="">Thanks you! I tried to make it as clear and detailed as possible. 🙂 </div><div class=""><br class=""></div><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">We did not discuss the 'indirect' idea at all on this list. Did you come up with it just now? In any case, my suggestion as to moving forward would be this:</div><div class=""><br class=""></div></div></div></div></blockquote></div>I was writing the proposal and was just about to write `factory init`, when it occurred to me: enums already have a keyword that does something very similar. It seemed to me that an initializer that doesn't initialize the instance in-place, but returns a completely separate instance from somewhere else, is kinda "indirectly" initializing the instance. Plus, the already established keyword and its semantic would reduce the learning curve for this new feature and separate it from a single specific use case (the "factory method" pattern).<div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">- Do you feel that both halves of your draft (expanding `return` in initializers, and `indirect` initializers) should absolutely be one proposal, or can they be separated?</div><div class=""><br class=""></div></div></div></div></blockquote><div class="">I think the `return` can be easily implemented first, while opening up an opportunity to later implement `indirect init`. The reason why I unified them was that the `return` idea on its own has very limited merit and could the thought of as a low-priority cosmetic enhancement. I wouldn't want it to be viewed that way because the primary purpose of that idea is to enable `indirect init` (which Cocoa and Cocoa Touch developers would be very happy about). </div><div class=""><br class=""></div><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">a) If they can be separated because each half has individual merit, then these ideas may be more likely to succeed as separate proposals, as each can be critiqued fully and judged independently as digestible units.</div></div></div></div></blockquote><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div></blockquote></div></div></div></div></div></div></div></div><div class="">Very good point. The challenge is to correctly separate them, without losing context in their respective proposals and without bleeding the proposals into each other.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div></blockquote></div><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">b) If you intend to tackle all your ideas all at once, that's going to be a much bigger change--in terms of review effort, likely bikeshedding, and implementation effort. It'll probably be best to solicit initial feedback on this list first about `indirect` initializers, even if just to familiarize the community with the idea, before launching into a pitch of the whole proposal.</div><div class=""><br class=""></div></div></div></div></blockquote></div><div class="">I'd never send a pull request to swift-evolution without thoroughly discussing it here. I just though, if I'm going to write a whole proposal with examples and motivation, it would be easier to demonstrate it and discuss in with the community If I just went ahead and wrote the whole thing and sent the link. This way it would be clearer to the reader and the discussed changes would be accurately reflected by the commits I'd make to my proposal.</div><div class=""><br class=""></div><div class="">Original Message</div><div class=""><br class=""></div><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 10, 2017, at 2:38 AM, Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div class="">On Fri, Jun 9, 2017 at 5:32 PM, Gor Gyolchanyan<span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span><span class=""><<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.c<wbr class="">om</a>></span><span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178Apple-converted-space"> </span>wrote:<br 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class="">Forked swift-evolution, created a draft proposal:</div><div class=""><br class=""></div><a href="https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-uniform-initialization.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/technogen-g<wbr class="">g/swift-evolution/blob/master/<wbr class="">proposals/NNNN-uniform-initial<wbr class="">ization.md</a><div class=""><br class=""></div><div class="">This is my first proposal, so I might have missed something or composed it wrong, so please feel free to comment, fork and send pull requests. 🙂<div class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178h5"><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""></div></blockquote></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is a very interesting read. We did not discuss the 'indirect' idea at all on this list. Did you come up with it just now? In any case, my suggestion as to moving forward would be this:</div><div class=""><br class=""></div><div class="">- Do you feel that both halves of your draft (expanding `return` in initializers, and `indirect` initializers) should absolutely be one proposal, or can they be separated?</div><div class=""><br class=""></div><div class="">a) If they can be separated because each half has individual merit, then these ideas may be more likely to succeed as separate proposals, as each can be critiqued fully and judged independently as digestible units.</div><div class=""><br class=""></div><div class="">b) If you intend to tackle all your ideas all at once, that's going to be a much bigger change--in terms of review effort, likely bikeshedding, and implementation effort. It'll probably be best to solicit initial feedback on this list first about `indirect` initializers, even if just to familiarize the community with the idea, before launching into a pitch of the whole proposal.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178h5"><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 3:24 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180Apple-interchange-newline"><div style="margin-bottom:0px" class="">Cool. I have reservations about idea #3, but we can tackle that another day. (Real life things beckon.) But suffice it to say that I now really, really like your idea #2.<br class=""><div class="gmail_quote"><div class="">On Fri, Jun 9, 2017 at 08:06 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word;line-break:after-white-space" class="">You know, come to think of it, I totally agree, and here's why:<div class="">A normal initializer (if #2 is accepted) would *conceptually* have the signature:</div><div class=""><br class=""></div><div class="">mutating func `init`(...) -> Self</div><div class=""><br class=""></div><div class="">Which would mean that both `self` and the returned result are non-optional.</div><div class="">A failable initializer could then have the signature:</div><div class=""><br class=""></div><div class="">mutating func `init`() -> Self?</div><div class=""><br class=""></div><div class="">Which would make the returned result optional, but leave `self` non-optional.</div><div class="">This would make `return nil` less out-of-place, like you said, while still leaving `self` as a set-exactly-once `inout Self`.</div><div class="">A factory initializer would then have the signature:</div><div class=""><br class=""></div><div class="">static func `init`(...) -> Self</div><div class=""><br class=""></div><div class="">or in case of a failable factory initializer:</div><div class=""><br class=""></div><div class="">static func `init`(...) -> Self?</div><div class=""><br class=""></div><div class="">Which would still make sense with the now legal `return ...` syntax, while adding the restriction of not having any `self` at all.</div><div class="">So, annotating the initializer with the keyword `factory` would cause it to change the signature as well as remove any compiler assumptions about the dynamic type of the returned instance.</div><div class=""><br class=""></div><div class="">In addition, idea #3 would be available for more deterministic in-place initialization.</div></div><div style="margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><br class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 2:47 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div class=""><div class=""><div class="gmail_quote"><div class="">On Fri, Jun 9, 2017 at 07:33 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class="">So far, we've discussed two ways of interpreting `self = nil`, both of which have a sensible solution, in my opinion:<div class=""><br class=""></div><div class="">1. It's a special rule like you said, which can be seen as counter-intuitive, but recall that `return nil` is just as much of a special rule and is also largely counter-intuitive.</div></div></blockquote><div class=""><br class=""></div></div></div></div><div class=""><div class=""><div class="gmail_quote"><div class="">`return nil` is “special,” but it doesn’t conflict with any other syntax because the initializer notionally has no return value. Personally, I have always disliked `return nil` in failable initializers for that reason, but I couldn’t come up with a better alternative.</div><div class=""><br class=""></div><div class="">Your proposed idea to allow returning any value is interesting because, in the case of a failable initializer, `return nil` continues to have the same meaning if we consider the return value of the initializer to be of type `Self?`. For that reason, I think your idea #2 is quite clever, and it would go a long way in making `return nil` a lot less odd. It also increases the expressivity of initializers because it allows one to set the value of self and also return in one statement, clearly demonstrating the intention that no other code in the initializer should be run before returning.</div><div class=""><br class=""></div><div class="">For all of those reasons, I think idea #2 is a winning idea.</div></div></div></div><div class=""><div class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class="">The benefit of `self = nil` is that it's much more in line with initialization semantics, it provides more uniform syntax and it's a bit less restrictive.<br class=""><div class=""><br class=""></div><div class="">2. It's an `inout Self!`, like Greg said, which can be seen as more cumbersome. Implicitly unwrapped optionals are a bit difficult, but this "variation" of it is much more restrictive then the normal ones, because unlike normal implicitly unwrapped optionals, this one cannot be accessed after being assigned nil (and it also cannot be indirectly assigned `nil`, because escaping `self` is not allowed before full initialization), so there is only one possible place it can be set to nil and that's directly in the initializer. This means that `self` can be safely treated as `inout Self` before being set to nil (and after being set to nil, it doesn't matter any more because you aren't allowed to access it, due to not being fully initialized).</div></div></div></blockquote><div class=""><br class=""></div><div class="">I have to say, I don’t like either of these explanations at all. I think having a “special” IUO is a difficult sell; it is just conceptually too complicated, and I don’t agree that it gains you much.</div><div class=""><br class=""></div><div class="">By your own admission, `self = nil` is wonky, and making the language wonkier because it currently has a parallel wonky feature in `return nil` seems like the wrong way to go. In addition, there’s nothing gained here that cannot be done with a defer statement; of course, defer statements might not be very elegant, but it would certainly be less wonky than inventing a new variation on an IUO to allow assignment of nil to self... For those reasons, I conclude that I’m not excited about your idea #1.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""></div><div class="">Overall, I'd go with #2 because it involves much less confusing magic and the restrictions of `self as inout Self!` are imposed by already existing and well-understood initialization logic, so the provided guarantees don't really come at the cost of much clarity.</div></div></div><div style="margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><br class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 2:23 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div class=""><br class=""><div class="gmail_quote"><div class="">On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word;line-break:after-white-space" class="">I think a good approach would be to have `self = nil` only mean `the initializer is going to fail` because if your type is ExpressibleByNilLiteral, it means that the `nil` of your type already carries the same meaning as if your type was not ExpressibleByNilLiteral and was an optional instead, so having a failable initializer doesn't really make sense in that case (since you could've initialized `self` to its own `nil` in case of failure). Still, some valid use cases may exist, so the natural (and quite intuitive) way to circumvent this would be to call `self.init(nilLiteral: ())` directly.</div><div style="margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">So you would create a special rule that `self = nil` means a different thing in an initializer than it does in a function? Essentially, then, you’re creating your own variation on an implicitly unwrapped optional, where `self` is of type `inout Self?` for assignment in initializers only but not for any other purpose. Implicitly unwrapped optionals are hard to reason about, and having a variation on it would be even harder to understand. I don’t think this is a workable design.</div><div class=""><br class=""></div><div class="">It might be possible to have `self` be of type `inout Self?`; however, I do think Greg is right that it would create more boilerplate than the current situation.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 2:07 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline">On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gor@gyolchanyan.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class="">The type of `self` could remain `inout Self` inside the failable initializer. The ability to assign nil would be a compiler magic (much like `return nil` is compiler magic) that is meant to introduce uniformity to the initialization logic.</div><br class=""><div class="">The idea is to define all different ways initialization can take place and expand them to be used uniformly on both `self` and all its members, as well as remove the ways that do not make sense for their purpose.</div><div class=""><br class=""></div><div class="">Currently, there are 3 ways of initializing self as a whole:</div><div class="">1. delegating initializer</div><div class="">2. assigning to self</div><div class="">3. returning nil</div><div class=""><div class=""><br class=""></div><div class="">#1: The delegating initializer is pretty much perfect at this point, in my opinion, so no changes there.</div><div class=""><br class=""></div><div class="">#2: The only exception in assigning to self is the `nil` inside failable initializers.</div><div class=""><br class=""></div><div class="">#3: The only thing that can be returned from an initializer is `nil`, which is compiler magic, so we can thing of it as a misnomer (because we aren't really **returning** anything).</div><div class=""><br class=""></div><div class="">If, for a second, we forget about potential factory initializers, returning anything from an initializer doesn't make much sense, because an initializer is conceptually meant to bring an existing object in memory to a type-specific valid state. This semantic was very explicitly in Objective-C with `[[MyType alloc] init]`. Especially since even syntactically, the initializer does not specify any return type, the idea of returning from an initializer is counter-intuitive both syntactically and semantically.</div><div class=""><br class=""></div><div class="">The actual *behavior* of `return nil` is very sensible, so the behavior, I imagine `self = nil`, would largely mean the same (except not needed to return immediately and allowing non-self-accessing code to be executed before return). Being able to assign `nil` to a non-optional (ExpressibleByNilLiteral doesn't count) may feel a bit wonky,</div></div></div></blockquote><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">What happens when Self is ExpressibleByNilLiteral and you want to initialize self to nil? That is what `self = nil` means if `self` is of type `inout Self`. If `self` is of type `inout Self` and Self is not ExpressibleByNilLiteral, then it must be an error to assign nil to self. Anything else does not make sense, unless `self` is of type `inout Self?`.</div><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">but not as wonky as returning nil from something that is meant to initialize an object in-place and doesn't look like it should return anything.</div><div class=""><br class=""></div><div class=""># Factory Initializers</div><div class=""><br class=""></div><div class="">In case of factory initializers, the much discussed `factory init` syntax could completely flip this logic, but making the initializer essentially a static function that returns an object. In this case the initializer could be made to specify the return type (that is the supertype of all possible factory-created objects) and assigning to self would be forbidden because there is not self yet:</div><div class=""><br class=""></div><div class="">extension MyProtocol {</div><div class=""><br class=""></div><div class="">public factory init(weCool: Bool) -> MyProtocol {</div><div class="">self = MyImpl() // error: cannot assign to `self` in a factory initializer</div><div class="">self.init(...) // error: cannot make a delegating initializer call in a factory initializer</div><div class="">if weCool {</div><div class="">return MyCoolImpl()</div><div class="">} else {</div><div class="">return MyUncoolImpl()</div><div class="">}</div><div class="">}</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class=""># In-place Member Initializers</div><div class=""><br class=""></div><div class="">In addition, member initialization currently is only possible with #2 (as in `self.member = value`), which could be extended in a non-factory initializer to be initializable in-place like this:</div><div class=""><br class=""></div><div class="">self.member.init(...)</div><div class=""><br class=""></div><div class="">This would compliment the delegating initialization syntax, while giving a more reliable performance guarantee that this member will not be copy-initialized.</div></div></div><div style="margin-bottom:0px;word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><br class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 1:32 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-interchange-newline"><div style="margin-bottom:0px" class="">If `self` is not of type `inout Self?`, then what is the type of `self` such that you may assign it a value of `nil`?<br class=""><br class="">It certainly cannot be of type `inout Self`, unless `Self` conforms to `ExpressibleByNilLiteral`, in which case you are able to assign `self = nil` an unlimited number of times–but that has a totally different meaning.<br class=""><br class="">Could `self` be of type `inout Self!`? Now that implicitly unwrapped optionals are no longer their own type, I’m not sure that’s possible. But even if it were, that seems unintuitive and potentially error-prone.<br class=""><br class="">So I think Greg is quite right that, to enable this feature, `self` would have to be of type `inout Self?`–which is intriguing but potentially more boilerplatey than the status quo.<br class=""><div class="gmail_quote"><div class="">On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word;line-break:after-white-space" class="">Good point, but not necessarily.<br class=""><div class="">Since you cannot access `self` before it being fully initialized and since `self` can only be initialized once, this would mean that after `self = nil`, you won't be allowed to access `self` in your initializer at all.You'll be able to do any potential, cleanup though.</div><div class="">Also, since there can be only one `self = nil`, there's no reason to treat `self` as `inout Self?`, because the only place it can be `nil` is the place it cannot be accessed any more.</div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 9, 2017, at 7:45 AM, Greg Parker <<a href="mailto:gparker@apple.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gparker@apple.com</a>> wrote:</div><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922m_1716065582357142928Apple-interchange-newline"><div style="margin-bottom:0px" class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div style="margin-bottom:0px" class=""><div class=""><br class="">1. Arbitrary `self` Assignments In Intializers<br class=""><br class="">The first ideas is to allow `self = nil` inside failable initializers (essentially making `self` look like `inout Self?` instead of `inout Self` with magical `return nil`), so that all initializers uniformly can be written in `self = ...` form for clarity and convenience purposes. This should, theoretically, be nothing but a `defer { return nil }` type of rewrite, so I don't see any major difficulties implementing this. This is especially useful for failable-initializing enums where the main switch simply assigns to self in all cases and the rest of the initializer does some post-processing.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don't see how to avoid source incompatibility and uglification of failable initializer implementations here. Allowing `self = nil` inside a failable initializer would require `self` to be an optional. That in turn would require every use of `self` in the initializer to be nil-checked or forced. I don't think that loss everywhere outweighs the gain of `self = nil` in some places.</div></div><br class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <span class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-converted-space"> </span><a href="mailto:gparker@apple.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none;margin-bottom:0px" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></blockquote></div></div></blockquote></div></div></div></blockquote></div></blockquote></div><br class=""></div></div></div></blockquote></div></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><div class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div style="margin:15px 0px" class=""><br class="m_1666313611408171104m_4423476558537416042m_-8889396346234607067m_241785386340440994m_-5415623279022033484m_1338021824996647178webkit-block-placeholder"></div></div><span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline!important" class="">______________________________<wbr class="">_________________</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class=""><span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline!important" class="">swift-evolution mailing list</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class=""></div></blockquote></div><br class=""></div></div></div></span></blockquote></div></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>