Please remove obscure "!" requirements for implicitly unwrapped optionals


(Amir Michail) #1

In particular, this should not be required in boolean contexts.

Is there any good reason why certain contexts require the “!” suffix?


(Chris Lattner) #2

! is used to in multiple different ways for IUO’s. What specifically are you objecting to? Please give an example, thanks!

-Chris

···

On Dec 3, 2015, at 3:10 PM, Amir Michail <a.michail@me.com> wrote:

In particular, this should not be required in boolean contexts.

Is there any good reason why certain contexts require the “!” suffix?


(Amir Michail) #3

I really don’t like having to put the ! suffix in boolean contexts:

"if displayFlag! { ... }" instead of "if displayFlag { … }" etc.

If you also want a way to compare with nil, then maybe have this for implicitly unwrapped optionals:

if displayFlag? == nil { … }

···

On Dec 3, 2015, at 6:49 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 3, 2015, at 3:10 PM, Amir Michail <a.michail@me.com> wrote:

In particular, this should not be required in boolean contexts.

Is there any good reason why certain contexts require the “!” suffix?

! is used to in multiple different ways for IUO’s. What specifically are you objecting to? Please give an example, thanks!

-Chris


(Per Melin) #4

I really don’t like having to put the ! suffix in boolean contexts:

To be explicit:

    let a: Bool! = false

    if a == false { } // Works as expected

    if !a { } // Works as expected

    if a { } // "error: optional type 'Bool!' cannot be used as a
boolean; test for '!= nil' instead"

Xcode "fixes" the last line like this:

    if (a != nil) { }

···

On Fri, Dec 4, 2015 at 1:03 AM, Amir Michail <a.michail@me.com> wrote:

"if displayFlag! { ... }" instead of "if displayFlag { … }" etc.

If you also want a way to compare with nil, then maybe have this for
implicitly unwrapped optionals:

if displayFlag? == nil { … }
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #5

Huh ok. Out of curiosity, why are you using IUOs for this? I’m interested in (continuing to ) dramatically reduce the prevalence of IOUs in code (eliminating the need to use them), and reduce their power in various ways. IUOs are one of the biggest sources of surprising behavior in Swift, and while they were a necessary feature to start with, their importance is going down over time.

-Chris

···

On Dec 4, 2015, at 1:18 PM, Per Melin <p@greendale.se> wrote:

On Fri, Dec 4, 2015 at 1:03 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

I really don’t like having to put the ! suffix in boolean contexts:

To be explicit:

    let a: Bool! = false

    if a == false { } // Works as expected

    if !a { } // Works as expected

    if a { } // "error: optional type 'Bool!' cannot be used as a boolean; test for '!= nil' instead"

Xcode "fixes" the last line like this:

    if (a != nil) { }


(Jon Shier) #6

I can’t answer for Per, but, at least in my iOS and OS X programming, I often find myself creating IUOs in view controller to represent properties that I’m guaranteed to have set before viewDidLoad, but don’t want a custom initializer, due to the pain of multiple required init methods. So while my IUO usage is perfectly safe, they’re rather awkward to use.
  That said, I’d have to see a specific proposal to tell if it’s any better for my usage than IUOs.

Jon Shier

···

On Dec 4, 2015, at 7:04 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 4, 2015, at 1:18 PM, Per Melin <p@greendale.se <mailto:p@greendale.se>> wrote:

On Fri, Dec 4, 2015 at 1:03 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

I really don’t like having to put the ! suffix in boolean contexts:

To be explicit:

    let a: Bool! = false

    if a == false { } // Works as expected

    if !a { } // Works as expected

    if a { } // "error: optional type 'Bool!' cannot be used as a boolean; test for '!= nil' instead"

Xcode "fixes" the last line like this:

    if (a != nil) { }

Huh ok. Out of curiosity, why are you using IUOs for this? I’m interested in (continuing to ) dramatically reduce the prevalence of IOUs in code (eliminating the need to use them), and reduce their power in various ways. IUOs are one of the biggest sources of surprising behavior in Swift, and while they were a necessary feature to start with, their importance is going down over time.

-Chris

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


(Chris Lattner) #7

Sure. For that use case, you’d be better served by a “delayed” property, which is initialized exactly once - but after init is done. There is some infrastructure that is missing to support that, but we’re interested in providing it.

-Chris

···

On Dec 4, 2015, at 4:19 PM, Jon Shier <jon@jonshier.com> wrote:

  I can’t answer for Per, but, at least in my iOS and OS X programming, I often find myself creating IUOs in view controller to represent properties that I’m guaranteed to have set before viewDidLoad, but don’t want a custom initializer, due to the pain of multiple required init methods. So while my IUO usage is perfectly safe, they’re rather awkward to use.
  That said, I’d have to see a specific proposal to tell if it’s any better for my usage than IUOs.


(Per Melin) #8

To be explicit:

    let a: Bool! = false

    if a == false { } // Works as expected

    if !a { } // Works as expected

    if a { } // "error: optional type 'Bool!' cannot be used as a
boolean; test for '!= nil' instead"

Xcode "fixes" the last line like this:

    if (a != nil) { }

Huh ok. Out of curiosity, why are you using IUOs for this?

I will leave that question to Amir who created this thread. I try to avoid
IUOs altogether. I only found the above when trying to figure out what the
heck he was talking about.

I’m interested in (continuing to ) dramatically reduce the prevalence of
IOUs in code (eliminating the need to use them), and reduce their power in
various ways. IUOs are one of the biggest sources of surprising behavior
in Swift, and while they were a necessary feature to start with, their
importance is going down over time.

What surprised me was the IIUOs. I did not expect Swift to happily help me
shoot myself in the foot quite so easily as this.

func isNegative(i: Int?) -> Bool {
    return i < 0
}

(No, I have never actually written code like this. I can't tell how likely
it is that I would make this mistake.)

···

On Sat, Dec 5, 2015 at 1:04 AM, Chris Lattner <clattner@apple.com> wrote:

On Dec 4, 2015, at 1:18 PM, Per Melin <p@greendale.se> wrote:


(Игорь Хмурец) #9

Also don’t like this pain with multiple required init methods in UIViewController, have to use IUO for properties here.
-Igor.

···

On Dec 5, 2015, at 03:19, Jon Shier <jon@jonshier.com> wrote:

  I can’t answer for Per, but, at least in my iOS and OS X programming, I often find myself creating IUOs in view controller to represent properties that I’m guaranteed to have set before viewDidLoad, but don’t want a custom initializer, due to the pain of multiple required init methods. So while my IUO usage is perfectly safe, they’re rather awkward to use.
  That said, I’d have to see a specific proposal to tell if it’s any better for my usage than IUOs.

Jon Shier

On Dec 4, 2015, at 7:04 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 4, 2015, at 1:18 PM, Per Melin <p@greendale.se <mailto:p@greendale.se>> wrote:

On Fri, Dec 4, 2015 at 1:03 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

I really don’t like having to put the ! suffix in boolean contexts:

To be explicit:

    let a: Bool! = false

    if a == false { } // Works as expected

    if !a { } // Works as expected

    if a { } // "error: optional type 'Bool!' cannot be used as a boolean; test for '!= nil' instead"

Xcode "fixes" the last line like this:

    if (a != nil) { }

Huh ok. Out of curiosity, why are you using IUOs for this? I’m interested in (continuing to ) dramatically reduce the prevalence of IOUs in code (eliminating the need to use them), and reduce their power in various ways. IUOs are one of the biggest sources of surprising behavior in Swift, and while they were a necessary feature to start with, their importance is going down over time.

-Chris

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #10

This is a separate problem. One of the things we plan to discuss (once things settle down a bit) is how to narrow the implicit conversion from T to T? in cases like this. This implicit promotion, as well as the T <-> T! promotions are problematic in a number of ways, and we need a holistic solution to them.

We have several specific ideas, but Joe Pamer is driving the effort and he is preoccupied with personal things for the next several weeks.

-Chris

···

On Dec 4, 2015, at 5:00 PM, Per Melin <p@greendale.se> wrote:

Xcode "fixes" the last line like this:

    if (a != nil) { }

Huh ok. Out of curiosity, why are you using IUOs for this?

I will leave that question to Amir who created this thread. I try to avoid IUOs altogether. I only found the above when trying to figure out what the heck he was talking about.

I’m interested in (continuing to ) dramatically reduce the prevalence of IOUs in code (eliminating the need to use them), and reduce their power in various ways. IUOs are one of the biggest sources of surprising behavior in Swift, and while they were a necessary feature to start with, their importance is going down over time.

What surprised me was the IIUOs. I did not expect Swift to happily help me shoot myself in the foot quite so easily as this.

func isNegative(i: Int?) -> Bool {
    return i < 0
}

(No, I have never actually written code like this. I can't tell how likely it is that I would make this mistake.)


Implicit promotion of Optional
(Per Melin) #11

I noticed that the promotion is recursive.

    let n: Int??? = 0
    true ? 4711 : n // => Optional(Optional(Optional(4711)))

Implicit promotions aside, what is the strong case for even having (T?, T?)
variants of the non-equatable comparable operators? I can see the
convenience when sorting optionals, but I must be missing something else?

Once everyone gets the bikeshedding over syntax out of their system,
hopefully the discussion can focus on more fundamental issues.

···

On Sat, Dec 5, 2015 at 2:35 AM, Chris Lattner <clattner@apple.com> wrote:

On Dec 4, 2015, at 5:00 PM, Per Melin <p@greendale.se> wrote:

What surprised me was the IIUOs. I did not expect Swift to happily help me
shoot myself in the foot quite so easily as this.

func isNegative(i: Int?) -> Bool {
    return i < 0
}

(No, I have never actually written code like this. I can't tell how likely
it is that I would make this mistake.)

This is a separate problem. One of the things we plan to discuss (once
things settle down a bit) is how to narrow the implicit conversion from T
to T? in cases like this. This implicit promotion, as well as the T <-> T!
promotions are problematic in a number of ways, and we need a holistic
solution to them.