[HN Gopher] The dark secret of Swift optionals
       ___________________________________________________________________
        
       The dark secret of Swift optionals
        
       Author : jakey_bakey
       Score  : 11 points
       Date   : 2024-08-19 19:12 UTC (1 days ago)
        
 (HTM) web link (jacobbartlett.substack.com)
 (TXT) w3m dump (jacobbartlett.substack.com)
        
       | mrkeen wrote:
       | > 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 wrote:
         | > 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.
        
       | turnsout wrote:
       | 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 wrote:
         | 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 wrote:
       | > 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 wrote:
         | 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 wrote:
       | 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 wrote:
       | 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 wrote:
         | 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)
        
       | happytoexplain wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-08-20 23:01 UTC)