[Draft] Abolish IUO type


(Anton Zhilin) #1

+1 for the idea. It will extract compiler magic for IUO types into a variable declaration attribute.
-1 for current wording/details.

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
2. We need to encourage using the attribute instead of `!`. In order to do this, I suggest finding a concise name for it. Like @IUO, but possibly more readable
3. In the future, `!` can be removed entirely and leave only the attribute. But not for now

- Anton


(Brent Royal-Gordon) #2

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.

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.)

···

--
Brent Royal-Gordon
Architechies


(Chris Willmore) #3

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

— Chris Willmore

···

On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent@architechies.com> wrote:


(Joe Groff) #4

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

···

On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent@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


(Chris Lattner) #5

@autounwrapped seems like the best description.

-Chris

···

On Mar 17, 2016, at 1:38 PM, Chris Willmore <cwillmore@apple.com> wrote:

(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


(Chéyo Jiménez) #6

I'd like something with the word optional in it:
@iuoptional
@unoptional // proposed new name for iuo :slight_smile:
@nonoptional

···

On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent@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

— Chris Willmore
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Willmore) #7

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.
— Chris Willmore

···

On Mar 17, 2016, at 2:19 PM, Joe Groff <jgroff@apple.com> wrote:

On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent@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.


(Chris Lattner) #8

I'd like something with the word optional in it:
@iuoptional
@unoptional // proposed new name for iuo :)
@nonoptional

The problem with this line of naming is that (in the new model) the value is already an optional. This is making the already-existing optional auto-unwrap itself.

-Chris

···

On Mar 17, 2016, at 4:42 PM, Cheyo Ximenez via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon <brent@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

— Chris Willmore
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(Brent Royal-Gordon) #9

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.

···

--
Brent Royal-Gordon
Architechies


(Chris Willmore) #10

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

— Chris Willmore

···

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.


(Chris Lattner) #11

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


(Brent Royal-Gordon) #12

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.

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.

···

--
Brent Royal-Gordon
Architechies


(Chris Willmore) #13

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

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.

My intent when writing the introduction was for it to serve as a summary of the proposal to follow. I feel like writing it like the above would bury the lede (i.e. the IUO type is going away).

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).

The concern about implying a syntax change is valid, and I’ve rewritten this section as a result. I don’t understand why we would propose separate @_autounwrappped and @_autounwrappedResult attributes, though. I figured the semantics of @_autounwrapped would depend on the kind of declaration that it is attached to — if it’s a function-like decl (i.e. function, method, initializer, or subscript), it applies to the result of the decl’s full application; otherwise, to the value of the decl itself.

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.

The main thing I had was consistency with other attributes. Are there currently any attributes that can’t be written explicitly like this? I agree that there’s no practical advantage, though.

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

Yeah, that sounds better. Fixed.

New draft: https://github.com/cwillmor/swift-evolution/blob/8f566a63d32dada678c9c0528abc8cbcf936398a/proposals/0000-abolish-iuo.md
Diff: https://github.com/cwillmor/swift-evolution/commit/8f566a63d32dada678c9c0528abc8cbcf936398a

Otherwise, LGTM!

Thanks!
— Chris Willmore

···

On Mar 17, 2016, at 5:04 PM, Chris Lattner <clattner@apple.com> wrote:

On Mar 17, 2016, at 4:18 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 17, 2016, at 2:29 PM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:


(Chris Lattner) #14

Right, that's part of the feature :-)

-Chris

···

On Mar 17, 2016, at 5:50 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

   @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.


(Jed Lewison) #15

I think you could express this as:

  let foo = functionReturningOptional()!

···

On Mar 17, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.


(Chris Lattner) #16

Sorry, less snarky answer:

You are right that today it is a regression vs:

let foo : ImplicitlyUnwrappedOptional = ...

However, I have never seen someone actually do that, and if they did, I would observe that the T is a lot more illuminating than the ! part of the type. Is there a concrete use case you are concerned about?

-Chris

···

On Mar 17, 2016, at 9:08 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 5:50 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.

Right, that's part of the feature :-)


(Step C) #17

That just forces the unwrap to the base type, it doesn't turn it into an autounwrapped (or IUO).

···

On Mar 17, 2016, at 10:26 PM, Jed Lewison via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 17, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.

I think you could express this as:

  let foo = functionReturningOptional()!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charles Srstka) #18

If you know something’s non-null, is there any advantage to keeping it in an implicitly-unwrapped optional instead of a normal non-optional type?

Charles

···

On Mar 17, 2016, at 11:08 PM, Step C via swift-evolution <swift-evolution@swift.org> wrote:

That just forces the unwrap to the base type, it doesn't turn it into an autounwrapped (or IUO).

On Mar 17, 2016, at 10:26 PM, Jed Lewison via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 17, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.

I think you could express this as:

  let foo = functionReturningOptional()!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(Jed Lewison) #19

Yeah, you’re right.

···

On Mar 18, 2016, at 12:08 AM, Step C <schristopher@bignerdranch.com> wrote:

That just forces the unwrap to the base type, it doesn't turn it into an autounwrapped (or IUO).

On Mar 17, 2016, at 10:26 PM, Jed Lewison via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 17, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

  @autounwrapped let foo = functionReturningOptional()

I *believe* that, without the `@autounwrapped` attribute, there's no way to go from T? to T! without actually restating T somewhere.

I think you could express this as:

  let foo = functionReturningOptional()!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #20

Performance, in certain circumstances. If you’re about to pass it to something that’s expecting a `T?` or `T!` instead of just a `T`, you wouldn’t have to rewrap it first.

(Come to think of it, is there a cost to converting between `T?` and `T!`, or do they get optimized into the same thing?)

- Dave Sweeris

···

On Mar 17, 2016, at 11:23 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

If you know something’s non-null, is there any advantage to keeping it in an implicitly-unwrapped optional instead of a normal non-optional type?

Charles