[swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Michel Fortin]

> * What is your evaluation of the proposal?

I don't like that proposal as it stands currently.

By the way, I don't use any IUO in my code, except sometime for @IBOutlets. I do encounter them sometime with external APIs, but the way they work in Swift 2 isn't causing me any problem. They are also very easy to reason about being types like regular optionals using a very similar syntax.


> * Is the problem being addressed significant enough to warrant a change to Swift?

It's hard to form a good opinion on the problem when there is no description of the problem.

The Motivation part of the proposal is basically a statement of intent:

• IUOs are a transitional technology
• we would like to limit their usage moving forward

Swift is expanding to Linux which has many unannotated APIs; so to me it seems the "transition" is still in progress, and will always be.

The same Motivation part says that IUOs are a valuable tool for importing external APIs and they are convenient in other places. There is not the slightest explanation of when or why they are inconvenient. There is surprisingly no mention of type propagation.


> * Does this proposal fit well with the feel and direction of Swift?

I don't like the syntax. In the current Swift, `T!` being the implicitly-unwrapped variant of type `T?` is something that is easy to understand. They look similar and have similar propagation behaviors since the two are types, so they are predictable.

This proposal proposes to change it to a declaration attribute while keeping the same syntax. The resulting concept is a hybrid declaration attribute/type modifier that changes the type from `T` to `T?` and allows implicit unwrap. What you actually see when reading the code is a pseudo-IUO `T!` type that isn't really a type and transform to `T?` when it propagates. I find it a bit strange and unsettling: if it's not a type, it shouldn't look like one. And if the type is a regular optional, that should be the type visible in the declaration. Otherwise it's confusing.

So I can't see a justification for replacing IUOs with this hard to describe part-type/part-attribute thing. I'm pretty sure we'd just be trading one problem (unwanted IUO propagation) for another (hard to grasp semantics).

 - - -

On a more general note, it seems to me that if the problem to solve is the silent propagation of IUOs, the compiler could simply require the propagation to be explicit by forcing the user to declare the type of every IUO variable:

	let x: Int! = nil
	let y = x       // error: must explicitly declare type Int!
	let z: Int! = x // ok

And that could work for generics too:

	let a = Array(x) // error: must explicitly declare type [Int!]
	let b: [Int!] = Array(x) // ok


> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A


> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal and some mails on the list that lead to that proposal.


-- 
Michel Fortin
https://michelf.ca