The dark secret of Swift optionals | Hacker News Reader

The dark secret of Swift optionals

jacobbartlett.substack.com

12 pointsjakey_bakey14 comments

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!"

> 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?

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

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

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.

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.

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.

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.

> 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?

They don't think about what it "is", only how the ? and ! syntax works.

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?? :)

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)

So Swift does implicit conversions?

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.

Reply on news.ycombinator.com