5 ms·

The dark secret of Swift optionals

12 points by jakey_bakey 2y ago

mrkeen 2y ago
> Your whole life was a lie. > Optionals were a 2-case enum the entire time. I'm not sure what I was supposed to think instead of this. But my question is, as a Swift programmer are you allowed to write this code yourself? > The ?, !, and ?? you know and love? Can you write an Either<> or a Parser<> (2- and 1-case enums respectively) which is driven by the known-and-loved ?, !, and ?? - or did the language designers keep that for themselves?
- Someone 2y ago
  > Can you write an Either<> or a Parser<> (2- and 1-case enums respectively) which is driven by the known-and-loved ?, !, and ?? - or did the language designers keep that for themselves? https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure#Operators https://docs.swift.org/swift-book/documentation/the-swift-pr...: “Although you can define custom operators that contain a question mark (?), they can’t consist of a single question mark character only. Additionally, although operators can contain an exclamation point (!), postfix operators can’t begin with either a question mark or an exclamation point. Note The tokens =, ->, //, /, /, ., the prefix operators <, &, and ?, the infix operator ?, and the postfix operators >, !, and ? are reserved. These tokens can’t be overloaded, nor can they be used as custom operators.” So, you can’t use the same operator names. I would think you can implement them using different names, though.
turnsout 2y ago
You'll see this occasionally when you print out a value that contains optionals in the console. But in 10 years of writing Swift code, I've never had any reason to interact with the underlying enum case values. I'm not sure why this should be surprising—the unwrapping operators are clearly syntactic sugar regardless of whether they're implemented in the standard library or in the Swift compiler.
- happytoexplain 2y ago
  I wish I could remember the specifics, but I have had cases where the compiler accepted `.none` but not `nil`. It's possible this has since been cleaned up, though.
coin 2y ago
> Optionals were a 2-case enum the entire time Why the drama, of course it is, what else what it be? The same is true for other languages, eg Scala.
- bena 2y ago
  I really don't know what else. I believe this is how dotnet implements them under the hood as well. I don't need the Optional to be "not an enum", I need it to function in certain ways. And syntactic sugar is 0 calorie. Add as much as you want. I don't care that "return x ?? y;" expands to "if (x == null) { return y; } else { return x; }" That's what it does. Math itself is essentially syntactic sugar for language to express manipulation of numbers.
deergomoo 2y ago
At the risk of sounding like "that guy", is this not common knowledge? I don't write a lot of Swift at all but I've read multiple introductions to the language's enums which are some variety of "those Optionals we've been using for a while? They're just an enum with syntactic sugar!"
w10-1 2y ago
The dark secret of Optional in Swift is all the extensions that make it work magic in situations far beyond the sugary ? ?? ! Disappointing, really, when someone finds the purloined letter hiding in plain sight and then... doesn't open it?? :)
- happytoexplain 2y ago
  Yup. I wonder if there is a single place documenting all the ways the compiler uses explicit knowledge of Optional? E.g. this uses no sugar, but it wouldn't work for any other wrapper type: func foo(string: Optional<String>) { . . . } let string: String = "just a string" foo(string: string)
  - grumpyprole 2y ago
    So Swift does implicit conversions?
    - happytoexplain 2y ago
      Not generally, no. Optional is a special case. It's the only special case I'm aware of - though possibly some of the things they added for SwiftUI might also do this? Like `Binding`? I could be wrong. Point is, it's not a feature available for developers to use with their own types. Edit: 'Binding' uses the PropertyWrapper attribute, which is similar in that it allows treating a wrapper type like the type it wraps. This is a language feature that is available to users. I'd be interested to know if Optional is the only "magical" type.
happytoexplain 2y ago
I'm happy to highlight "obvious" knowledge, since really there's no such thing. This particular one hits close to home because of the sheer number of "highly experienced" Swift developers I have interviewed who didn't know this.
- mcphage 2y ago
  > This particular one hits close to home because of the sheer number of "highly experienced" Swift developers I have interviewed who didn't know this. Out of curiosity, what do they think it is instead?
  - happytoexplain 2y ago
    They don't think about what it "is", only how the ? and ! syntax works.

12 points by jakey_bakey 2y ago

> Your whole life was a lie. > Optionals were a 2-case enum the entire time. I'm not sure what I was supposed to think instead of this. But my question is, as a Swift programmer are you allowed to write this code yourself? > The ?, !, and ?? you know and love? Can you write an Either<> or a Parser<> (2- and 1-case enums respectively) which is driven by the known-and-loved ?, !, and ?? - or did the language designers keep that for themselves?

Someone 2y ago
> Can you write an Either<> or a Parser<> (2- and 1-case enums respectively) which is driven by the known-and-loved ?, !, and ?? - or did the language designers keep that for themselves? https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure#Operators https://docs.swift.org/swift-book/documentation/the-swift-pr...: “Although you can define custom operators that contain a question mark (?), they can’t consist of a single question mark character only. Additionally, although operators can contain an exclamation point (!), postfix operators can’t begin with either a question mark or an exclamation point. Note The tokens =, ->, //, /, /, ., the prefix operators <, &, and ?, the infix operator ?, and the postfix operators >, !, and ? are reserved. These tokens can’t be overloaded, nor can they be used as custom operators.” So, you can’t use the same operator names. I would think you can implement them using different names, though.

turnsout 2y ago

You'll see this occasionally when you print out a value that contains optionals in the console. But in 10 years of writing Swift code, I've never had any reason to interact with the underlying enum case values. I'm not sure why this should be surprising—the unwrapping operators are clearly syntactic sugar regardless of whether they're implemented in the standard library or in the Swift compiler.

happytoexplain 2y ago
I wish I could remember the specifics, but I have had cases where the compiler accepted `.none` but not `nil`. It's possible this has since been cleaned up, though.

coin 2y ago

> Optionals were a 2-case enum the entire time Why the drama, of course it is, what else what it be? The same is true for other languages, eg Scala.

bena 2y ago
I really don't know what else. I believe this is how dotnet implements them under the hood as well. I don't need the Optional to be "not an enum", I need it to function in certain ways. And syntactic sugar is 0 calorie. Add as much as you want. I don't care that "return x ?? y;" expands to "if (x == null) { return y; } else { return x; }" That's what it does. Math itself is essentially syntactic sugar for language to express manipulation of numbers.

deergomoo 2y ago

At the risk of sounding like "that guy", is this not common knowledge? I don't write a lot of Swift at all but I've read multiple introductions to the language's enums which are some variety of "those Optionals we've been using for a while? They're just an enum with syntactic sugar!"

w10-1 2y ago

The dark secret of Optional in Swift is all the extensions that make it work magic in situations far beyond the sugary ? ?? ! Disappointing, really, when someone finds the purloined letter hiding in plain sight and then... doesn't open it?? :)

happytoexplain 2y ago
Yup. I wonder if there is a single place documenting all the ways the compiler uses explicit knowledge of Optional? E.g. this uses no sugar, but it wouldn't work for any other wrapper type: func foo(string: Optional<String>) { . . . } let string: String = "just a string" foo(string: string)
- grumpyprole 2y ago
  So Swift does implicit conversions?
  - happytoexplain 2y ago
    Not generally, no. Optional is a special case. It's the only special case I'm aware of - though possibly some of the things they added for SwiftUI might also do this? Like `Binding`? I could be wrong. Point is, it's not a feature available for developers to use with their own types. Edit: 'Binding' uses the PropertyWrapper attribute, which is similar in that it allows treating a wrapper type like the type it wraps. This is a language feature that is available to users. I'd be interested to know if Optional is the only "magical" type.

happytoexplain 2y ago

I'm happy to highlight "obvious" knowledge, since really there's no such thing. This particular one hits close to home because of the sheer number of "highly experienced" Swift developers I have interviewed who didn't know this.

mcphage 2y ago
> This particular one hits close to home because of the sheer number of "highly experienced" Swift developers I have interviewed who didn't know this. Out of curiosity, what do they think it is instead?
- happytoexplain 2y ago
  They don't think about what it "is", only how the ? and ! syntax works.