<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p><code>self.</code> is a different story. It’s absence has become quite popular out in the wild and it’s becoming even more optional in Swift 4. A week or two ago Slava Pestov said on twitter that he has fixed several bugs that made <code>self.</code> even more optional though the whole language.</p>
<p>Personally I don’t care if other people are using this convenience, I’ll let them have that option :-) , but I simply cannot get along with the idea that there could a global variable or a function that has the exact same signature as one of the type members, which could lead to unexpected bugs which are really hard to track.</p>
<p>If I would granted the chance to tackle again the access modifier on extensions, I’d do it and try to remove that feature from the language. I’m not using it, I won’t ever use it and I haven’t seen any *good* swift code using it. It’s just too much sugar if you ask me.</p>
<p>Same goes for <code>indirect enum</code>. How rare is it used? If it’s used how complex are the enum cases that it cannot be applied on the cases only which needs it?</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1497170006308611840" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (<a href="mailto:gor@gyolchanyan.com">gor@gyolchanyan.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div></div><div>
<title></title>
There was another proposal that got rejected, which was about
forcing the usage of `self.` on members.
<div class="">
<div class="">I pretty much *require* it in my code for two
reasons:</div>
<div class="">* The understandable requirement of `self.` in
closures conflicts with the lack of `self.` in methods, which is
confusing.</div>
<div class="">* The ability to refer to globals and members in the
same way is also making the code harder to read.</div>
<div class=""><br class=""></div>
<div class="">The same goes for using `Self.` for associated types
and type aliases inside protocols, because it's very easy to
accidentally confuse them with global types, which would mess up
the protocol.</div>
<div class="">I know that this adds a bit of code, but it does not
make the code less readable (in the contrary) and modern IDEs are
very capable of code completion, which negates the problem of
having to type more text manually.</div>
<div class=""><br class=""></div>
<div class="">The argument agains this was something like "this is
not worth sacrificing such a convenience".</div>
<div class="">On the other hand, on numerous occasions I've heard
another argument against a proposal that said "it's not worth
gaining terseness by sacrificing clarity".<br class="">
<div class="">
<div><br class=""></div>
<div>This direct contradiction of priorities is worrying to
me.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jun 11, 2017, at 11:21 AM, Adrian Zubarev
<<a href="mailto:adrian.zubarev@devandartist.com" class="">adrian.zubarev@devandartist.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<p style="margin: 15px 0px; -webkit-margin-before: 0px;" 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 style="margin: 15px 0px;" class="">The<span class="Apple-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; -webkit-margin-before: 0px;" class="">indirect</code><span class="Apple-converted-space"> </span>keyword is literally the same
story. The docs only says that this is only a shortcut.</p>
<blockquote style="margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px; color: rgb(119, 119, 119);" class="">
<div style="margin: 0px; -webkit-margin-before: 0px;" 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.“</div>
</blockquote>
<p style="margin: 15px 0px;" 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 style="margin: 15px 0px;" class=""><br class="webkit-block-placeholder"></div>
</div>
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div>
<br class="">
<div id="bloop_sign_1497168891326406912" class="bloop_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="airmail_on" style="margin: 15px 0px;">Am 11. Juni 2017 um
10:12:38, Gor Gyolchanyan (<a href="mailto:gor@gyolchanyan.com" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">gor@gyolchanyan.com</a>) schrieb:</p>
<blockquote type="cite" class="clean_bq" style="margin: 15px 0px;">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div class=""></div>
<div class=""><span style="margin-top: 0px; margin-bottom: 0px;" 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`?</span>
<div class=""><span style="margin-top: 0px; margin-bottom: 0px;" 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.</span></div>
<div class=""><span style="margin-top: 0px; margin-bottom: 0px;" class="">If the `indirect` confusion becomes real, I'd suggest
getting rid of `indirect enum` and using `indirect case`
instead.<br class=""></span>
<div class=""><span style="margin-top: 0px; margin-bottom: 0px;" class=""><br class=""></span>
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;"><span style="margin-top: 0px; margin-bottom: 0px;" class="">On Jun 11, 2017, at
11:05 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">swift-evolution@swift.org</a>>
wrote:</span></div>
<span style="margin-top: 0px; margin-bottom: 0px;" class=""><br class="Apple-interchange-newline"></span>
<div class="" style="margin-bottom: 0px;">
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<p class="" style="margin: 15px 0px; -webkit-margin-before: 0px;">
<span style="margin-top: 0px; margin-bottom: 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.</span></p>
<p class="" style="margin: 15px 0px;"><span style="margin-top: 0px; margin-bottom: 0px;" class="">For instance the
function from this example<span class="Apple-converted-space" style="-webkit-margin-before: 0px;"> </span><a href="https://stackoverflow.com/a/43123783/4572536" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none; -webkit-margin-before: 0px;">https://stackoverflow.com/a/43123783/4572536</a><span class="Apple-converted-space"> </span>could
be used directly inside an<span class="Apple-converted-space"> </span><code class="" 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;">init</code>:</span></p>
<pre class="" 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;"><code class="" 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; -webkit-margin-before: 0px;">class MyView : UIView {
indirect init() {
return MyView.instantiateFromXib()
// Or after SR-0068
return Self.instantiateFromXib()
}
}
</code></pre>
<p class="" style="margin: 15px 0px;">There is still one little
thing that bothers me, it might be a little bit confusing to have
two different meanings of<span class="Apple-converted-space" style="-webkit-margin-before: 0px;"> </span><code class="" 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; -webkit-margin-before: 0px;">indirect</code><span class="Apple-converted-space"> </span>on
enums.</p>
<pre class="" 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;"><code class="swift" 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; -webkit-margin-before: 0px;">indirect enum ArithmeticExpression {
case number(Int)
case addition(ArithmeticExpression, ArithmeticExpression)
case multiplication(ArithmeticExpression, 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 class="" style="margin: 15px 0px;"><br class="webkit-block-placeholder" style="-webkit-margin-before: 0px;"></div>
</div>
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<div id="bloop_customfont" class="" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;">
<br class=""></div>
<br class="">
<div id="bloop_sign_1497167373101756160" class="bloop_sign">
<div class="" style="font-family: helvetica, arial; font-size: 13px;">
-- <br class="">
Adrian Zubarev<br class="">
Sent with Airmail</div>
</div>
<br class="">
<p class="airmail_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" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">swift-evolution@swift.org</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div class=""></div>
<div class="">
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;">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 class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span></div>
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;"><a href="https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md</a></span></div>
<span class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span>
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;"><span class="" style="margin-top: 0px; margin-bottom: 0px;">On Jun 10, 2017, at 12:43
PM, Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">gor@gyolchanyan.com</a>>
wrote:</span></div>
<span class="" style="margin-top: 0px; margin-bottom: 0px;"><br class="Apple-interchange-newline"></span>
<div class="" style="margin-bottom: 0px;">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;">Hi, Riley!</span></div>
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span></div>
<span class="" style="margin-top: 0px; margin-bottom: 0px;">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 class="" style="margin-top: 0px; margin-bottom: 0px;">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 class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span>
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;"><span class="" style="margin-top: 0px; margin-bottom: 0px;">On Jun 10, 2017, at 8:36 PM,
Riley Testut <<a href="mailto:rileytestut@gmail.com" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">rileytestut@gmail.com</a>>
wrote:</span></div>
<span class="" style="margin-top: 0px; margin-bottom: 0px;"><br class="Apple-interchange-newline"></span>
<div class="" style="margin-bottom: 0px;">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<span class="" style="margin-top: 0px; margin-bottom: 0px;">Hi Gor
👋</span>
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span></div>
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;">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 class="" style="margin-top: 0px; margin-bottom: 0px;"><br class=""></span></div>
<div class=""><span class="" style="margin-top: 0px; margin-bottom: 0px;">Here’s my proposal for
reference:<span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e</a><span class="Apple-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" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 10, 2017, at 3:33 AM,
Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">swift-evolution@swift.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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 dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><br class=""></div>
</div>
</div>
</div>
</blockquote>
</div>
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div dir="ltr" class="" style="margin-top: 0px; margin-bottom: 0px;">
<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" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 10, 2017, at 2:38 AM,
Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">swift-evolution@swift.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<div dir="ltr" class="">On Fri, Jun 9, 2017 at 5:32 PM, Gor
Gyolchanyan<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:gor@gyolchanyan.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">gor@gyolchanyan.com</a>></span><span class="Apple-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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<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" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">https://github.com/technogen-<wbr class="">gg/swift-evolution/blob/<wbr class="">master/proposals/NNNN-uniform-<wbr class="">initialization.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="h5">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px; margin-bottom: 0px;"></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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<div class="">
<div class="">
<div class="h5">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 3:24 PM,
Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="m_-7329774452902408180Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">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 dir="ltr" class="">On Fri, Jun 9, 2017 at 08:06 Gor
Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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 class="" style="margin-top: 0px; word-wrap: break-word; line-break: after-white-space;">
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 class="" style="margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 2:47 PM,
Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="m_-7329774452902408180m_-1696318748622386158Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<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" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<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 class="" style="margin-top: 0px; word-wrap: break-word; line-break: after-white-space;">
<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 class="" style="margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 2:23 PM,
Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<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" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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 class="" style="margin-top: 0px; word-wrap: break-word; line-break: after-white-space;">
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 class="" style="margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 2:07 PM,
Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<div class="" 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;">
<br class="m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline">
On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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 class="" style="margin-top: 0px; margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<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 class="" 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;">
<br class=""></div>
<div class="" 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;">
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 class="" 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;">
<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 class="" style="margin-top: 0px; word-wrap: break-word; line-break: after-white-space;">
<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 class="" style="margin-bottom: 0px; word-wrap: break-word; line-break: after-white-space;">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 1:32 PM,
Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">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" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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 class="" style="margin-top: 0px; word-wrap: break-word; line-break: after-white-space;">
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 class="" style="word-wrap: break-word; line-break: after-white-space;">
<div class=""><br class="">
<div class=""><br class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 9, 2017, at 7:45 AM,
Greg Parker <<a href="mailto:gparker@apple.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">gparker@apple.com</a>>
wrote:</div>
<br class="m_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922m_1716065582357142928Apple-interchange-newline">
<div class="" style="margin-bottom: 0px;">
<div class="" style="word-wrap: break-word; line-break: after-white-space;"><br class="">
<div class="">
<blockquote type="cite" class="" style="margin: 15px 0px;">
<div class="" style="margin-top: 0px;">On Jun 8, 2017, at 5:09 AM,
Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">swift-evolution@swift.org</a>>
wrote:</div>
<div class="" style="margin-bottom: 0px;">
<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_-7329774452902408180m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-converted-space"> </span><a href="mailto:gparker@apple.com" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">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" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none; margin-bottom: 0px;">
https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">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>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
https://lists.swift.org/mailman/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="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">
https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div>
</div>
</blockquote>
</div>
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<div class="" style="-webkit-margin-before: 0px; margin: 15px 0px;"><br class="webkit-block-placeholder" style="-webkit-margin-before: 0px;"></div>
</div>
<span class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254); float: none; display: inline !important;">_______________________________________________</span><br class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<span class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254); float: none; display: inline !important;">
swift-evolution mailing list</span><br class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<a href="mailto:swift-evolution@swift.org" class="" 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; -webkit-text-stroke-width: 0px;">
swift-evolution@swift.org</a><br class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" 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; -webkit-text-stroke-width: 0px;">
https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="" 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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
<div class="bloop_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; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);">
<br class="Apple-interchange-newline"></div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>