<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="">So you would you be happy if failable inits were declared like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">init() -> self? {}</div></blockquote><div class=""><br class=""></div><div class="">Unfortunately, Swift decided to make init() a special case thing. It's also the only function type that has special rules around accessing properties, the only one that cannot be named differently, the only one that has special rules around recursing or forwarding to other init() calls, and many other special rules and considerations. </div><div class=""><br class=""></div><div class="">The ability to use optionals is one of the key components to Swift's error handling story. Why should initializers not be able to participate in that story? I don't agree with your consistency argument; init() is already completely inconsistent from every other function in Swift. It's a side-effect of all of the other choices around init() that cause the inconsistent syntax with other functions signatures.</div><div class=""><br class=""></div><div class="">-David</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 9:20 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">let i: Int = Int.init(123)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">would not compile if that initializer had a return type of Void rather than Int.</div></div></blockquote></div>No one can argue the observation that init-methods have return values (although I think it's rather uncommon to invoke them that way) — but that is not my point:<div class="">Let's imagine I write a library with a numeric type, and define the "+"-operator to perform a multiplication.</div><div class="">Given this,</div><div class="">let x: StringIntLiteralConvertible = 2 + 5</div><div class="">should assign x a value of 10: That is how the operation is defined (like "init" is defined to return self), and according to your argumentation, everything is fine.</div><div class="">Nonetheless, I'd say this operator is inconsistent, because it contradicts to common behavior, and "+" should be linked to addition.</div><div class="">Initializers behave similar (on another level, though):</div><div class="">They have the signature of a void function, they have the body of a void function — but yet they return something.</div><div class=""><br class=""></div><div class="">You are right that this is actually a topic on its own, as "init?" just emphasizes the "oddity", because suddenly there is a need to manually add a return statement for one case...</div><div class=""><br class=""></div><div class="">Tino</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>