[swift-evolution] [Draft] Abolish IUO type

Joe Groff jgroff at apple.com
Thu Mar 17 16:19:12 CDT 2016


> On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> 1. We have to add @implicitly_unwrapped attribute to the proposal. I hate implied "attributes", available only to compiler. The wording needs to be reformulated in terms of this attribute
>> 
>> Agree.
>> 
>>> 2. We need to encourage using the attribute instead of `!`.
>>> 3. In the future, `!` can be removed entirely and leave only the attribute. But not for now
>> 
>> Disagree. As I mentioned earlier in the thread, IUOs are going to become less common on Apple platforms, but they are here to stay in Swift as a whole.
> 
> I agree with this.
>> 
>>> In order to do this, I suggest finding a concise name for it. Like @IUO, but possibly more readable
>> 
>> I do agree that we should look for a shorter, better name. I suggest `@autounwrap`, by analogy with `@autoclosure`. Both features insert invisible syntax at usage sites to make an expression of one type appear to be an expression of a different type.
>> 
>> (Actually, I think that `@autoclosure` is a great analogy for this feature in many respects.)
> 
> The similarity to @autoclosure is a good observation.
> 
> It sounds like an explicit attribute name may be a necessary part of this proposal rather than a thought for the future. So far we’ve heard:
> 
> @implicitly_unwrapped
> @iuo
> @autounwrap

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.

-Joe


More information about the swift-evolution mailing list