[Idea] Continue to abolish IUO


(Anton Zhilin) #1

First of all, I tried to change the original proposal to add actual
@autounwrapped attribute to Swift.
Because "explicit is better than implicit" and consistency and so on.

Its authors did not pay much attention, and so I'm going to create a
separate proposal for that purpose.

Next, implicitly unwrapped optional was designed purely for bridging to
Objective-C (and now C).
Notation T! that is still used in Swift code, is misleading, because it's
not an actual type.

So I also propose that T! notation is reserved for entities imported from
Objective-C.
Swift code, which needs that behaviour, such as delayed initialization,
will use @autounwrapped.
It's more clear and explicit about this being a property behaviour and not
a type, with all consequences.

What do you think?

- Anton


(Chris Lattner) #2

Hi Anton,

I agree with you in theory, and this is definitely important to discuss. My main concern is about the readability impact that this will have on the readability of unaudited APIs. Here are two random unaudited examples, with the rules we have today:

JSValue / Darwin:
  func defineProperty(property: String!, descriptor: AnyObject!)
  func strcat(_: UnsafeMutablePointer<Int8>!, _: UnsafePointer<Int8>!) -> UnsafeMutablePointer<Int8>!

If we got rid of !, we’d end up with:

  func defineProperty(property: @autounwrapped String?, descriptor: @autounwrapped AnyObject?)
  func strcat(_: @autounwrapped UnsafeMutablePointer<Int8>?, _: @autounwrapped UnsafePointer<Int8>?) -> @autounwrapped UnsafeMutablePointer<Int8>?

Here are some problems:
a) @autounwrapped ends up dominating the signature, since it is longer than many type names.

b) While it is appropriate for return values and properties, it isn’t the right attribute name for parameters. There, a better name would be “@unaudited”. When passing a parameter, there is no behavioral difference between T! and T? after all.

I suppose that you could argue that we should just drop annotations completely for parameters. My concern with doing that is that it would lose the distinction between audited APIs that accept nil and do something meaningful with it, and those that have been unaudited.

-Chris

···

On Apr 10, 2016, at 4:45 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

First of all, I tried to change the original proposal to add actual @autounwrapped attribute to Swift.
Because "explicit is better than implicit" and consistency and so on.

Its authors did not pay much attention, and so I'm going to create a separate proposal for that purpose.

Next, implicitly unwrapped optional was designed purely for bridging to Objective-C (and now C).
Notation T! that is still used in Swift code, is misleading, because it's not an actual type.

So I also propose that T! notation is reserved for entities imported from Objective-C.
Swift code, which needs that behaviour, such as delayed initialization, will use @autounwrapped.
It's more clear and explicit about this being a property behaviour and not a type, with all consequences.

What do you think?


(Anton Zhilin) #3

I agree and I'm keeping that in mind. So when I wrote:

So I also propose that T! notation is reserved for entities imported from

Objective-C.
I meant that T! will still be used for unaudited imported APIs, not to
cause the bloat of function signatures you mentioned.
No, I'm not going to argue for complete removal of IUO.

- Anton

···

2016-04-10 17:59 GMT+03:00 Chris Lattner <clattner@apple.com>:

On Apr 10, 2016, at 4:45 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

First of all, I tried to change the original proposal to add actual
@autounwrapped attribute to Swift.
Because "explicit is better than implicit" and consistency and so on.

Its authors did not pay much attention, and so I'm going to create a
separate proposal for that purpose.

Next, implicitly unwrapped optional was designed purely for bridging to
Objective-C (and now C).
Notation T! that is still used in Swift code, is misleading, because it's
not an actual type.

So I also propose that T! notation is reserved for entities imported from
Objective-C.
Swift code, which needs that behaviour, such as delayed initialization,
will use @autounwrapped.
It's more clear and explicit about this being a property behaviour and not
a type, with all consequences.

What do you think?

Hi Anton,

I agree with you in theory, and this is definitely important to discuss.
My main concern is about the readability impact that this will have on the
readability of unaudited APIs. Here are two random unaudited examples,
with the rules we have today:

JSValue / Darwin:
func defineProperty(property: String!, descriptor: AnyObject!)
func strcat(_: UnsafeMutablePointer<Int8>!, _: UnsafePointer<Int8>!)
-> UnsafeMutablePointer<Int8>!

If we got rid of !, we’d end up with:

func defineProperty(property: @autounwrapped String?, descriptor:
@autounwrapped AnyObject?)
func strcat(_: @autounwrapped
UnsafeMutablePointer<Int8>?, _: @autounwrapped UnsafePointer<Int8>?)
-> @autounwrapped UnsafeMutablePointer<Int8>?

Here are some problems:
a) @autounwrapped ends up dominating the signature, since it is longer
than many type names.

b) While it is appropriate for return values and properties, it isn’t the
right attribute name for parameters. There, a better name would be
@unaudited”. When passing a parameter, there is no behavioral difference
between T! and T? after all.

I suppose that you could argue that we should just drop annotations
completely for parameters. My concern with doing that is that it would
lose the distinction between audited APIs that accept nil and do something
meaningful with it, and those that have been unaudited.

-Chris