Introducing `Unwrappable`, a biased unwrapping protocol

Evolution Pitches
61

Unwrapabble is an information extraction approach, similar to how @stephencelis 's autosynthesized members work. Unlike try? and try!, the original instance can be stored and re-accessed, used in a switch statement, and so forth.

What Unwrappable does is:

  • Allows you to use built-in Swift constructs like guard, optional-chaining, and nil-coalescing to access payloads and move them forward with both functional and procedural approaches.
  • Extends these courtesies beyond Optional, so you can add streamlined use like for testScore? in scores, enabling you to focus only those cases of interest at that point of use.

Unwrappable is not sugar for discarding information in any way and is not the code equivalent of try?. Its features focus on language integration.

62

The Unwrappable.unwrap method doesn't reduce the amount of wrapping. It changes the type of the outermost wrapper to Optional. Compare with Optional.unsafelyUnwrapped or Alamofire.Result.unwrap(), both of which actually remove a layer of wrapper.

I don't think unwrap is the right name for this method.

1 Like
63

That's an excellent point. It converts a payload into an Optional-unwrap scenario. Would prepareForUnwrapping be a better (if wordier) alternative? If not, can you suggest any names that better represent the payload redeployment?

64

How about wrapped() or wrappedValue()?

In the interest of this protocol or a subprotocol supporting assignment through optional chaining, it makes sense to aim for symmetry with the setter:

wrapped() -> Wrapped?
setWrapped(_ newValue: Wrapped)
65

Makes sense. Depending on how the protocol will exactly define the "biased" value to be, the property can probably be named biasedValue (or replacing biased with the chosen meaning, e.g. success, etc...)

66

I’d name it for what it does:

protocol ImplicitlyOptionalConvertible {
    associatedtype Wrapped
    var optional: Wrapped? { get }
}
1 Like
67

I feel like this is a win for the compiler and a mistake for the language. Is there no alternative which could reduce the amount of magic in the compiler around optionals but which does not introduce potentially harmful semantics to the language?

68

Maybe I lost track of the discussion, but I don't even know what benefits the compiler is going to get from this any more. The protocol has evolved to basically being sugar for omitting a single computed property. Not much win.

If we were to extend if-let constructs to handle else cases with payloads (e.g an error from a try?), maybe we would have some behaviour worth generalising. Our current system basically only make sense for Optional.

And if you're mapping your type in to an Optional, is it really such a burden to call a single property? Does it really need to be implicit? Are we actually removing/simplifying compiler magic in that case, or just adding cruft?

6 Likes
69

The semantics of Unwrappable, as shown by the protocol in the proposal, is "give me a representation of your type as it was an Optional of some wrapped internal type": this representation (Optional) discards any other information. It's information extraction that ignores the context at call site, and I personally don't find it useful. It would be great if the context was not ignored, and collected at call site, like with an applicative functor chain of any kind.

I'd find super useful to use built-in constructs like guard if the else case actually presented the alternative content for (optional) handling. Same with optional chaining or chaining in general, that in Swift is semantically equivalent to flatMap.

There's certainly some convenience there, like the usage of for _? in or case _?:, but I don't find it major, and would turn implicit something that, to me, should be explicit. So, I personally don't find it useful, but that's my preference.

What I don't like in general, and I strongly think it's wrong for the language, is the fact that the proposal wants to use a compiler feature that's specific to optionals for other types: I think the language should instead move towards more generic constructs, like generalized binding for monads, something that we only have right now for Optionals. I understand that the convenience the proposal focuses on is at call site, but I'd rather have a little less convenient but more extensible Swift, with less compiler magic, and more options for developers.

1 Like
70

As I consider this proposal more, I think that we should be careful overloading ? any further. Currently, the connective point for each use is Optional. This change would make that only technically true and I think that the story for beginners would suffer for it. More and more, I think that ? should be a privileged operator, the proposal should move away from overloading ?, and toward allowing either one other–specific–construction for syntactic sugar in this vein or arbitrary operators for constructions like this.

2 Likes