> * 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
