<div dir="ltr">Given that the Proposal has been rejected I've been thinking alot of this may be cleared up if optionals had a consistent syntax.<div><br></div><div>Object()</div><div>OptionalObject()</div><div><br></div><div>Are the same, as are</div><div><br></div><div>value</div><div>optionalValue</div><div>forcedUnwrappedValue<br></div><div><br></div><div>and:</div><div><br></div><div>function()</div><div>optionalFunction()</div><div>forcedUnwrappedValue()<br></div><div><br></div><div>But when it comes to protocols, I've had to write it like this:<br></div><div><br></div><div>optionalProtocolMethod()</div><div>forcedProtocolMethod!()</div><div><br></div><div>I would love to take a page out of Ruby's book which has ! for things that are dangerous and ? for boolean expression. Instead for Swift we could have ? for optional returns and ! for forced unwrapped.</div><div><br></div><div>So we would have:</div><div><br></div><div>Object()</div><div>OptionalObject?()</div><div><br></div><div>value</div><div>optionalValue?</div><div>forcedUnwrappedValue!<br></div><div><br></div><div><div>function()</div><div>optionalFunction?()</div><div>forcedUnwrappedValue!()</div></div><div><br></div><div><div>optionalProtocolMethod?()</div><div>forcedProtocolMethod!()</div></div><div><br></div><div>You may think this is silly but I've had crashes due to function arguments being mapped into swift from objective-c as forced un-wrapped due to the lack of non-null and null marking. </div><div><br></div><div>If the name of the property had a "!" in it then I would have noticed it.</div><div><br></div><div>The same with falliable initializers. It would be a lot clearer to me that Object?() could fail. </div><div><br></div><div>IT also confuses me that some non-optional protocol methods have to have the ! in the name.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Head of Trolls</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 9, 2016 at 6:10 PM, David Owens II via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>So you would you be happy if failable inits were declared like this:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>init() -> self? {}</div></blockquote><div><br></div><div>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><br></div><div>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><br></div><div>-David</div><div><br></div><br><div><blockquote type="cite"><div><div class="h5"><div>On Mar 9, 2016, at 9:20 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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>Let's imagine I write a library with a numeric type, and define the "+"-operator to perform a multiplication.</div><div>Given this,</div><div>let x: StringIntLiteralConvertible = 2 + 5</div><div>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>Nonetheless, I'd say this operator is inconsistent, because it contradicts to common behavior, and "+" should be linked to addition.</div><div>Initializers behave similar (on another level, though):</div><div>They have the signature of a void function, they have the body of a void function — but yet they return something.</div><div><br></div><div>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><br></div><div>Tino</div></div></div></div><span class="">_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>