<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>Well I was referring to the title of (1) not to the addition it creates with failable initializers, which I guess is fine by me, but I’d need a more detailed proposal or draft to provide better feedback though. </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_1496937144345899008" 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 8. Juni 2017 um 17:51:28, 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>
Not exactly. #1 is an addition to the language syntax. It's simply
a convenient way of expressing failure in a failable initializer
the logic of which is already implemented, while extending the
syntax in a way that would require zero effort to enable a
potential factory initializers.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jun 8, 2017, at 6:45 PM, 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="">
Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is
a chance for Swift to support<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="">init(_ other: Self) { self = other }</code><span class="Apple-converted-space"> </span>for classes. Joe Groff replied
this is called “factory initializer”.</p>
<p style="margin: 15px 0px;" class="">This feature is highly needed
for all the iOS developers out there who abuse NIBs and create a
custom<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="">UIView</code><span class="Apple-converted-space"> </span>in a nib file then instead of
assigning it to a<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;" class="">UIViewController</code><span class="Apple-converted-space"> </span>they nest it in another
container view, which is not what it’s meant for in the first
place. Factory initializer could solve this issue by simply
assigning the instance created from a nib file to<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;" class="">self</code>. The nested view hierarchy would disappear and
it won’t be that much of an abuse anymore.<span class="Apple-converted-space"> </span></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_1496936399254590976" 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 8. Juni 2017 um
14:09:30, Gor Gyolchanyan via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a>) schrieb:</p>
<blockquote type="cite" class="clean_bq" style="margin: 15px 0px;">
<div class="">
<div class=""></div>
<div class=""><span style="margin-top: 0px; margin-bottom: 0px;" class="">Disclaimer: I do realize that any of the following ideas
may have been discussed before and/or there might be a good reason
for their lack of implementation, so please go easy in me.
🙂<br 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="">
<br class="">
2. Arbitrary `return` Statements In Intializers<br class="">
<br class="">
The second idea is to allow `return ...` inside all initializers,
which should also, theoretically, be a simple rewrite to `self =
...; return`. This one is to complement the existing `return nil`
and allow some super-short initializers with a switch that returns
in all cases or a more complex initializer that has a lot of guard
statements.<br class="">
<br class="">
2.1. Future Factory Initializers<br class="">
<br class="">
In addition, the `return ...` syntax has the benefit for potential
factory initializers. So far, the proposals for factory
initializers involved a keyword attached to the initializer, which
just complicates the lexical structure of the language and adds
unnecessary complication to the interface of types. Currently,
factory initializers imported from Objective-C or from C using the
`__attribute__((swift_name("MyType.init(self:...)")))` look like
normal initializers (an in case of C, the return value doesn't even
have to be related to the enclosing type in any way), but behave as
you'd expect: you call the initializer and the result is a value
that *should* be a subtype of the type you've called the
initializer for. So, if in the future Swift gets native factory
initializers (including, most importantly, in protocols), it won't
require special syntax, because simply returning an instance of a
subtype (with a compile-time check, of course) would look and
behave very intuitively. This would also be very useful for
singletons, which would use a private initializer for creating the
instance and a public factory initializer for returning
it.<br class="">
<br class="">
3. Failable Member Initialization<br class="">
<br class="">
The third idea is to allow writing `self.member = MemberType?(...)`
or `self.member = .init?(...)` (the exact syntax is up to debate)
inside failable initializers, which would be simply rewritten
as:<br class="">
<br class="">
guard let _self_member = MemberType(...) else {<br class="">
return nil<br class="">
}<br class="">
self.member = _self_member<br class="">
<br class="">
This will dramatically reduce the boilerplate and visual clutter
form complex failable initializers that call other failable
initializers. A good use case would be complex
`LosslessStringConvertible` types with many
`LosslessStringConvertible` members.<br class="">
<br class="">
So, what do you guys think?<br class="">
<br 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;" 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;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</span></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>
</div>
</blockquote>
</div>
<br class="">
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>