This is looking great, and I agree that explaining it in terms of an attribute makes sense. Some more comments:
"This proposal seeks to remove the ImplicitlyUnwrappedOptional type from the Swift type system and replace it with an IUO attribute on declarations. Appending ! to the type of a Swift declaration will give it optional type and annotate the declaration with an attribute stating that it may be implicitly unwrapped when used.”
This is more of a statement of implementation. I would start out with the first two sentences of your motivation, and then make a more direct statement about the purpose & payoff, something along the lines of:
"The ImplicitlyUnwrappedOptional ("IUO") type is a valuable tool for importing Objective-C APIs where the nullability of a parameter or return type is unspecified. It also represents a convenient mechanism for working through definite initialization problems in initializers.
This proposal aims to make the behavior of these values more simple, local, and predictable by making any force-unwrap operations happen locally, and only when necessary for an expression to type check.”
With this change, your motivation section can be simplified or just merged into the intro.
This heavily implies a major syntax change, which you aren’t proposing:
I propose demoting implicitly unwrapped optionals from being a first-class type in the Swift type system to being an attribute on declarations in Swift.
How about something like:
In this proposal, we keep the surface syntax of T! for these types, in the following locations <the list>. However, internally, the compiler will model this as a property of the declaration that it is applied to, not as part of the formal type system. No human would ever write or observe the attribute, but we will refer to them as @_autounwrapped (properties and parameters) and @_autounwrappedResult (function and subscript results).
What is the advantage to allowing someone to write the attribute?
It is possible to attach @implicitly_unwrapped to a declaration explicitly,
It seems like this unnecessarily complicates the surface model of Swift. To me, it seems like there is no advantage to having two ways to spell this.
Instead of:
The effect of this behavior is that the result of any expression that refers to an IUO declaration of type T? will either...
How about:
The effect of this behavior is that the result of any expression that refers to a value declared as T! will either
Otherwise, LGTM!
-Chris
···
On Mar 17, 2016, at 4:18 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 17, 2016, at 2:29 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
I'm not sure this is a great idea yet. Punishing IUOs with verbose syntax may feel good, but runs the danger of making projected Swift interfaces from unaudited C and Objective-C APIs too noisy to read. Our current syntax was motivated by a strong desire to ensure that Swift interfaces remain readable, even for foreign APIs that haven't been annotated with Swift interop in mind yet.
I don’t think that Brent and I are suggesting that attribute syntax for IUOs should be mandatory or even recommended, merely that it should exist. That way we can talk about the feature in terms of the underlying attribute-based representation without it being some hidden, exclusively compiler-internal thing.
That's my position as well. I will probably almost always use the `!` sugar, but when I'm thinking about the feature, and perhaps occasionally when I'm doing something kind of tricky with it, having the desugared Optional + @autounwrap representation may come in handy.
I’ve updated the proposal to more explicitly call out the need for a named decl attribute. The name is subject to further discussion, of course:
https://github.com/cwillmor/swift-evolution/blob/9dce2e8d6c1b27f3370e8c2ba8d5b549ab8f6954/proposals/0000-abolish-iuo.md