[swift-evolution] Brainstorming: New operator type - chaining

[Joseph Lord]

>> On 31/01/2016 05:20, Chris Lattner via swift-evolution wrote:
>> On Jan 30, 2016, at 3:06 PM, Joseph Lord via swift-evolution <swift-evolution at swift.org> wrote:
>> Use case 2 - Chaining on custom types
>> 
>> And this especially may not be feasible and I may be out of my depth describing the requirement but it feels like a more general case so at least worth airing):
> 
> I’m not certain I understand the problem you’re looking to solve here, but I think it would be great (though probably very low priority) to open up the functionality of the postfix optional chaining operator to other types.  This could allow its monadic binding (aka railroad short circuiting) behavior to be extended to other types like Result, a left-biased-either, or an arbitrary type defined by the user.  A natural approach would be to capture this behavior in an “chainable” protocol of some sort.
> 
> This is low priority because I don’t know a lot of killer applications of it, I’m motivated by my ivory tower desire to push compiler magic into the standard library.  It bugs me that optional has sugar and other behavior that other types can’t participate in.
> 
> -Chris

Thanks,

I can understand that it is low priority and know that you have a huge amount on your plate before 3.0. I don't really have a killer application because I think it is really syntactic sugar for a map like function with the benefit of removing the explicit closure. If I'm right and it is just syntactic sugar then there is no urgency but I did want to mention the idea at this stage in case there were any potential impacts on the ABI so that at least it could be considered and allowed for if necessary. 

Especially if the academic issue of the special treatment of optionals bothers you as it does me a little I'm hopeful that this will be addressed at some point (4.0 or 5.0 maybe) but don't want to add additional pressure to the Core Team. 

The personal use case is the first one I mentioned in the original message, wanting an asserting variant of optional chaining. That it is not currently possible led me to consider a more general possible solution and what else could be done with it. The Either use case was a bigger stretch for me as I don't usually use that style but it felt like the thing missing to enable alternatives to optionals being used as first class citizens with the powers of optionals in projects that choose to use them. 

To elaborate on the relationship between optional chaining and map which reassures me it is syntactic sugar and is unlikely to be an ABI issue I looked at how to do the equivalent operations (I'm sure this is obvious to Chris and many others of you but I thought it worth sharing as it helped me think about things)

The current optional chaining is equivalent to this on an rvalue:

foo?.bar()

foo.map { $0.bar() } // except this warns about unused results

And this on a lvalue version:

foo?.bar = 1

foo.map { $0.bar = 1 }

As always in these most simple examples the sugar doesn't feel that worthwhile but the benefits are shown in more complex or repeated use. An example of an assignment to a property that is accessed through two levels of optional would look quite ugly as I think it would need a double map but an `if let` with two binds would be the better option without optional chaining.

Joseph