6 ms·

> Swift seems horribly complicated and over-specified. The Dart compiler knows if I do a null-check, it can treat following references as safe, instead of if le

> Swift seems horribly complicated and over-specified. The Dart compiler knows if I do a null-check, it can treat following references as safe, instead of if let x = x etc. `if let x = x` is an alternative to a null check, it's not as if now you need both a null check and an `if let`. What makes an `if let` more complicated?

refulgentis 3y ago
There are now 2x as many syntaxes for the same operation, if let and if != null
- RetpolineDrama 3y ago
  It's not the same op though. One is a check, the other creates an in-context copy that's unwrapped from the optional. The compiler of course optimizes this out but it's not the same.
  - refulgentis 3y ago
    Right. In Dart they are the same. In Swift they are distinct.
    - mckn1ght 3y ago
      They have different use cases. if x != nil is to do some work without needing x, because you'd still have to unwrap it if you used it. That's what if let y = x is for, it creates a safe lexical context to use the unwrapped value. And then you have guard let y = x which is a stronger guarantee that no code further down in the context is executed if x is nil. This helps to write happy-path code with early returns, avoiding pyramids of doom and encouraging writing code where all the assumptions are listed up front with logic handling exceptional cases before finally arriving at the logic that works under all the assumptions. Dart feels like a step backwards after seeing the benefits these provide.
      - afavour 3y ago
        > They have different use cases. But there’s also no harm in combining them. I agree with the OP, TypeScript does what they describe Dart doing and I find it much simpler than the way Swift does it. It’s never confusing.
        mckn1ght 3y ago
        > But there’s also no harm in combining them Disagree. I’ve seen people write things like the following: if x != nil { x!.foo() } and then later the x != nil condition is changed to no longer check for nil, or the x!.foo() is moved out of that lexical scope elsewhere, or copypastad, and then the force unwrap crashed. I’ve seen similar yet more subtle bugs with soft unwraps instead of forced: x?.foo() Not possible if you use if let y = x . If you copypasta the inner scope with the different variable name then it won’t compile. (ofc these are trivial representative examples, in reality these were lexical scopes with many lines and more complicated code) It’s not just about how the code looks when you write it, it’s the paths that can be taken by future maintenance programmers. I‘ve complained about the large surface area of swift syntax, stdlib etc in the past, but I don’t personally find this specific thing confusing.
        refulgentis 3y ago
        For removing the null check, that, of course, would cause a compiler error. For moving the force unwrapped out of the if, that's a problem with force unwrapping, not combining the syntaxes.
        saagarjha 3y ago
        Changing the type of something based on a conditional check is not great, because if I wanted a non-optional I would request it. Sometimes a nil check is literally just a nil check. What if I want to set the value back to nil if it is not-nil? Why should I have to wrap things back in an optional if I want to pass it along as such?
        mraleph 3y ago
    - teho 3y ago
      In Dart if you want to narrow down a nullable final class variable, it is not enough to do if (value == null) { // value is still nullable here } instead you need to first capture the value final value = this.value if (value == null) { // value is non-null } Swift's guard and if let syntax seems way nicer here. In swift, it's also nice to destructure nested nullable values using if let. if let value = object.object?.value { // value is non null } In dart you'd need to first assign this into a local variable and then do the null check which is unnecessarily verbose.
      - mraleph 3y ago
        In Dart 3 instead of declaring the variable and then comparing you can simply write an if-case pattern: if (value case final value?) { // value is a fresh final variable }
        teho 3y ago
        The more you know, I had totally missed this.
        Someone 3y ago
        So Dart is moving in the Swift direction, which has if let value = value { // a new binding named ‘value’ refers to value, unwrapped } or (newer syntax that I initially found even weirder than the older one, but both grew on me) if let value { // a new binding named ‘value’ refers to value, unwrapped } (The old version will remain, as it is more flexible, allowing such things as if let baz = foo.bar(42) { // a new binding named ‘baz’ refers to foo.bar(42), unwrapped } )
secretsatan 3y ago
Small change made in swift means an unwrap can just be `if let x { }` Which while small, is great if you do it all the time. Swift though made me question how much I used optionals, now I get annoyed if they're over used, it usually means someone down the line has not made a decision, they propagate through the program and eventually someone wonders why they didn't get a value. I like the Result type and the Flexibility of the Enums a lot for this
- secretsatan 3y ago
  Tbh, i now look at optionals as another colour when i read this https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... You return an optional with no reason, it colours all subsequent calls. When i was younger, i thought of them as an extension of bool, yes/no/maybe, but now, was it cancelled? Did an error occur? Did it just timed out? How many cpu cycles am i wasting throughout my code because every thing down the line checks it for null? It snowballs

refulgentis 3y ago

There are now 2x as many syntaxes for the same operation, if let and if != null

RetpolineDrama 3y ago
It's not the same op though. One is a check, the other creates an in-context copy that's unwrapped from the optional. The compiler of course optimizes this out but it's not the same.
- refulgentis 3y ago
  Right. In Dart they are the same. In Swift they are distinct.
  - mckn1ght 3y ago
    They have different use cases. if x != nil is to do some work without needing x, because you'd still have to unwrap it if you used it. That's what if let y = x is for, it creates a safe lexical context to use the unwrapped value. And then you have guard let y = x which is a stronger guarantee that no code further down in the context is executed if x is nil. This helps to write happy-path code with early returns, avoiding pyramids of doom and encouraging writing code where all the assumptions are listed up front with logic handling exceptional cases before finally arriving at the logic that works under all the assumptions. Dart feels like a step backwards after seeing the benefits these provide.
    - afavour 3y ago
      > They have different use cases. But there’s also no harm in combining them. I agree with the OP, TypeScript does what they describe Dart doing and I find it much simpler than the way Swift does it. It’s never confusing.
      - mckn1ght 3y ago
        > But there’s also no harm in combining them Disagree. I’ve seen people write things like the following: if x != nil { x!.foo() } and then later the x != nil condition is changed to no longer check for nil, or the x!.foo() is moved out of that lexical scope elsewhere, or copypastad, and then the force unwrap crashed. I’ve seen similar yet more subtle bugs with soft unwraps instead of forced: x?.foo() Not possible if you use if let y = x . If you copypasta the inner scope with the different variable name then it won’t compile. (ofc these are trivial representative examples, in reality these were lexical scopes with many lines and more complicated code) It’s not just about how the code looks when you write it, it’s the paths that can be taken by future maintenance programmers. I‘ve complained about the large surface area of swift syntax, stdlib etc in the past, but I don’t personally find this specific thing confusing.
        refulgentis 3y ago
        For removing the null check, that, of course, would cause a compiler error. For moving the force unwrapped out of the if, that's a problem with force unwrapping, not combining the syntaxes.
      - saagarjha 3y ago
        Changing the type of something based on a conditional check is not great, because if I wanted a non-optional I would request it. Sometimes a nil check is literally just a nil check. What if I want to set the value back to nil if it is not-nil? Why should I have to wrap things back in an optional if I want to pass it along as such?
        mraleph 3y ago
  - teho 3y ago
    In Dart if you want to narrow down a nullable final class variable, it is not enough to do if (value == null) { // value is still nullable here } instead you need to first capture the value final value = this.value if (value == null) { // value is non-null } Swift's guard and if let syntax seems way nicer here. In swift, it's also nice to destructure nested nullable values using if let. if let value = object.object?.value { // value is non null } In dart you'd need to first assign this into a local variable and then do the null check which is unnecessarily verbose.
    - mraleph 3y ago
      In Dart 3 instead of declaring the variable and then comparing you can simply write an if-case pattern: if (value case final value?) { // value is a fresh final variable }
      - teho 3y ago
        The more you know, I had totally missed this.
      - Someone 3y ago
        So Dart is moving in the Swift direction, which has if let value = value { // a new binding named ‘value’ refers to value, unwrapped } or (newer syntax that I initially found even weirder than the older one, but both grew on me) if let value { // a new binding named ‘value’ refers to value, unwrapped } (The old version will remain, as it is more flexible, allowing such things as if let baz = foo.bar(42) { // a new binding named ‘baz’ refers to foo.bar(42), unwrapped } )

secretsatan 3y ago

Small change made in swift means an unwrap can just be `if let x { }` Which while small, is great if you do it all the time. Swift though made me question how much I used optionals, now I get annoyed if they're over used, it usually means someone down the line has not made a decision, they propagate through the program and eventually someone wonders why they didn't get a value. I like the Result type and the Flexibility of the Enums a lot for this

secretsatan 3y ago
Tbh, i now look at optionals as another colour when i read this https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... You return an optional with no reason, it colours all subsequent calls. When i was younger, i thought of them as an extension of bool, yes/no/maybe, but now, was it cancelled? Did an error occur? Did it just timed out? How many cpu cycles am i wasting throughout my code because every thing down the line checks it for null? It snowballs