IUO in Swift 3.0


(David Hart) #1

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 <https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md> gives a clear example that:

func f() -> Int! { return 3 } // f: () -> Int?, has IUO attribute
// ...
let x3: Int! = f() // succeeds; x3: Int? = .some(3), has IUO attribute
// ...
func g() -> Int! { return nil } // f: () -> Int?, has IUO attribute
// ...
let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 playground show that they are still of type Int!. Did I miss something?

David.


(Joe Groff) #2

SE-0054 hasn't been fully implemented yet. The stricter implicit promotions are mostly there, but the IUO type still exists.

-Joe

···

On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 gives a clear example that:

func f() -> Int! { return 3 }
// f: () -> Int?, has IUO attribute
// ...

let x3: Int! = f()
// succeeds; x3: Int? = .some(3), has IUO attribute
// ...

func g() -> Int! { return nil }
// f: () -> Int?, has IUO attribute
// ...

let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 playground show that they are still of type Int!. Did I miss something?


(Jonathan Cotton) #3

I was also surprised this type still exists as I'd taken that the proposal was for the removal of IUO as an explicit type, but after some testing of IUO propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been changed to meet the desired behaviour in the spec, specifically, I now don't need to define a separate interface signature to specifically expect type T!

···

On 21 Jun 2016, at 21:22, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 gives a clear example that:

func f() -> Int! { return 3 }
// f: () -> Int?, has IUO attribute
// ...

let x3: Int! = f()
// succeeds; x3: Int? = .some(3), has IUO attribute
// ...

func g() -> Int! { return nil }
// f: () -> Int?, has IUO attribute
// ...

let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 playground show that they are still of type Int!. Did I miss something?

SE-0054 hasn't been fully implemented yet. The stricter implicit promotions are mostly there, but the IUO type still exists.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jonathan Cotton) #4

I was also surprised this type still exists as I'd taken that the proposal was for the removal of IUO as an explicit type, but after some testing of IUO propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been changed to meet the desired behaviour in the spec, specifically, I now don't need to define a separate interface signature to specifically expect type T!

···

On 21 Jun 2016, at 21:22, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 gives a clear example that:

func f() -> Int! { return 3 }
// f: () -> Int?, has IUO attribute
// ...

let x3: Int! = f()
// succeeds; x3: Int? = .some(3), has IUO attribute
// ...

func g() -> Int! { return nil }
// f: () -> Int?, has IUO attribute
// ...

let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 playground show that they are still of type Int!. Did I miss something?

SE-0054 hasn't been fully implemented yet. The stricter implicit promotions are mostly there, but the IUO type still exists.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #5

I think that there is some confusion here: it is true that IUO exists internally as a type within the compiler, but the idea of our current implementation is that that is just an implementation detail within the compiler (similar to LValueType, which has no user syntax), not an exposed part of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift. This is the way to model the IUO declaration modifier, as outlined in the proposal.

-Chris

···

On Jun 21, 2016, at 1:39 PM, Jonathan Cotton via swift-evolution <swift-evolution@swift.org> wrote:

I was also surprised this type still exists as I'd taken that the proposal was for the removal of IUO as an explicit type, but after some testing of IUO propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been changed to meet the desired behaviour in the spec, specifically, I now don't need to define a separate interface signature to specifically expect type T!


(David Hart) #6

Is there a bug tracking the remaining part of the implementation?
Shouldn’t the proposal still be under “Not yet implemented” as its not completely implemented?

David.

···

On 21 Jun 2016, at 22:22, Joe Groff <jgroff@apple.com> wrote:

On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 gives a clear example that:

func f() -> Int! { return 3 }
// f: () -> Int?, has IUO attribute
// ...

let x3: Int! = f()
// succeeds; x3: Int? = .some(3), has IUO attribute
// ...

func g() -> Int! { return nil }
// f: () -> Int?, has IUO attribute
// ...

let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 playground show that they are still of type Int!. Did I miss something?

SE-0054 hasn't been fully implemented yet. The stricter implicit promotions are mostly there, but the IUO type still exists.

-Joe


(Joe Groff) #7

As implemented in the seed, T! still leaks into the user type system.

-Joe

···

On Jun 21, 2016, at 9:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Jun 21, 2016, at 1:39 PM, Jonathan Cotton via swift-evolution <swift-evolution@swift.org> wrote:

I was also surprised this type still exists as I'd taken that the proposal was for the removal of IUO as an explicit type, but after some testing of IUO propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been changed to meet the desired behaviour in the spec, specifically, I now don't need to define a separate interface signature to specifically expect type T!

I think that there is some confusion here: it is true that IUO exists internally as a type within the compiler, but the idea of our current implementation is that that is just an implementation detail within the compiler (similar to LValueType, which has no user syntax), not an exposed part of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift. This is the way to model the IUO declaration modifier, as outlined in the proposal.


(Chris Lattner) #8

Are there specific examples of that? Those examples are bugs, that should be fixed.

-Chris

···

On Jun 22, 2016, at 8:56 AM, Joe Groff <jgroff@apple.com> wrote:

I think that there is some confusion here: it is true that IUO exists internally as a type within the compiler, but the idea of our current implementation is that that is just an implementation detail within the compiler (similar to LValueType, which has no user syntax), not an exposed part of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift. This is the way to model the IUO declaration modifier, as outlined in the proposal.

As implemented in the seed, T! still leaks into the user type system.


(Joe Groff) #9

var x = [Int!]()

-Joe

···

On Jun 22, 2016, at 1:03 PM, Chris Lattner <clattner@apple.com> wrote:

On Jun 22, 2016, at 8:56 AM, Joe Groff <jgroff@apple.com> wrote:

I think that there is some confusion here: it is true that IUO exists internally as a type within the compiler, but the idea of our current implementation is that that is just an implementation detail within the compiler (similar to LValueType, which has no user syntax), not an exposed part of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift. This is the way to model the IUO declaration modifier, as outlined in the proposal.

As implemented in the seed, T! still leaks into the user type system.

Are there specific examples of that? Those examples are bugs, that should be fixed.

-Chris


(David Hart) #10

Just to close the discussion: have all the bugs pertaining to the incomplete implementation of SE-0054 been tracked? If not, I don’t mind writing them.

David.

···

On 22 Jun 2016, at 22:07, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 1:03 PM, Chris Lattner <clattner@apple.com> wrote:

On Jun 22, 2016, at 8:56 AM, Joe Groff <jgroff@apple.com> wrote:

I think that there is some confusion here: it is true that IUO exists internally as a type within the compiler, but the idea of our current implementation is that that is just an implementation detail within the compiler (similar to LValueType, which has no user syntax), not an exposed part of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift. This is the way to model the IUO declaration modifier, as outlined in the proposal.

As implemented in the seed, T! still leaks into the user type system.

Are there specific examples of that? Those examples are bugs, that should be fixed.

-Chris

var x = [Int!]()

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution