[swift-evolution] Remove Failable Initializers

[James Campbell]

Given that the Proposal has been rejected I've been thinking alot of this
may be cleared up if optionals had a consistent syntax.

Object()
OptionalObject()

Are the same, as are

value
optionalValue
forcedUnwrappedValue

and:

function()
optionalFunction()
forcedUnwrappedValue()

But when it comes to protocols, I've had to write it like this:

optionalProtocolMethod()
forcedProtocolMethod!()

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.

So we would have:

Object()
OptionalObject?()

value
optionalValue?
forcedUnwrappedValue!

function()
optionalFunction?()
forcedUnwrappedValue!()

optionalProtocolMethod?()
forcedProtocolMethod!()

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.

If the name of the property had a "!" in it then I would have noticed it.

The same with falliable initializers. It would be a lot clearer to me that
Object?() could fail.

IT also confuses me that some non-optional protocol methods have to have
the ! in the name.



*___________________________________*

*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Wed, Mar 9, 2016 at 6:10 PM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

> So you would you be happy if failable inits were declared like this:
>
> init() -> self? {}
>
>
> 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.
>
> 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.
>
> -David
>
>
> On Mar 9, 2016, at 9:20 AM, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> let i: Int = Int.init(123)
> would not compile if that initializer had a return type of Void rather
> than Int.
>
> 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:
> Let's imagine I write a library with a numeric type, and define the
> "+"-operator to perform a multiplication.
> Given this,
> let x: StringIntLiteralConvertible = 2 + 5
> 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.
> Nonetheless, I'd say this operator is inconsistent, because it contradicts
> to common behavior, and "+" should be linked to addition.
> Initializers behave similar (on another level, though):
> They have the signature of a void function, they have the body of a void
> function — but yet they return something.
>
> 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...
>
> Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/230144fd/attachment.html>