I am probably completely mis-understanding what you want. Your 1st example, isn't it equivalent to:<div><br></div><div> foo!.bar()<br><br>On Sunday, 31 January 2016, Joseph Lord via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31/01/2016 01:14, Howard Lovatt via swift-evolution wrote:<br>
> What is wrong with flatMap returning an Optional? Like Scala does.<br>
><br>
<br>
Using map or a function taking a closure is less clear to read than an chaining mechanism.<br>
<br>
For the first usecase (which is really the most trivial case of optional chaining:<br>
<br>
> assert(foo != nil)<br>
> foo?.bar()<br>
><br>
> I would only want to do:<br>
><br>
> foo±.bar()<br>
><br>
<br>
_ = foo.aMap { $0.bar() }<br>
<br>
If you can image a multiple step chain it could clearly get more complicated.<br>
<br>
I don't think that there is a way to avoid the closures within current Swift and any map/flatMap based approach.<br>
<br>
I'm not familiar with Scala so I may have misunderstood exactly what you meant.<br>
<br>
Joseph<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sunday, 31 January 2016, Joseph Lord via swift-evolution<br>
<<a>swift-evolution@swift.org</a> <mailto:<a>swift-evolution@swift.org</a>>> wrote:<br>
<br>
Currently there are three types of operator: prefix, infix and<br>
postfix and most of the Swift operations can be defined using these<br>
and implemented for additional types and they cover most use cases<br>
but there are features in the Swift language which cannot be<br>
replicated and customised with these.<br>
<br>
In particular there is the optional chaining use of `?` for which I<br>
can see no way of producing customised versions of or adapting to<br>
types other than optionals (e.g. custom Either types or other<br>
monadic types).<br>
<br>
I’m not sure about the feasibility of this change or what knockon<br>
effects might be. This is meant as exploratory suggestion that may<br>
not reach proposal stage.<br>
<br>
Would be interested to know:<br>
1) If this is feasible.<br>
2) If it is interesting to people.<br>
3) What if anything should be possible for l-values (optional<br>
chaining works on them but what should be possible.<br>
4) Any other good alternatives.<br>
<br>
I picture that the chaining operator function would be called with<br>
the left hand side value and could be required to return a value of<br>
a type such as this ChainValueResult:<br>
<br>
enum ChainValueResult<A,C,D> {<br>
case continue(A, C->D),<br>
case stop(D)<br>
}<br>
<br>
The logic then applied to this enum would be in case of continue to<br>
apply the C->D function to the result of continuing the chain which<br>
is applied to the A value. In the case of stop it is to simply<br>
return the value of type D.<br>
<br>
I have used this enum in the draft code below. Please note that the<br>
code below doesn't compile and that if really being used the<br>
inference system would need to account for the return type of the<br>
ongoing chain.<br>
<br>
Use case 1 - Custom optional chaining behaviour<br>
<br>
The particular thing that I would like use this for is to make a<br>
custom asserting variant of the optional chaining operator. I<br>
already do this with nil coalescing (it is currently the only custom<br>
operator in my code) but a shorthand for this would be good:<br>
<br>
assert(foo != nil)<br>
foo?.bar()<br>
<br>
I would only want to do:<br>
<br>
foo±.bar()<br>
<br>
func ± <A, C>(lhs: A?)->ChainValueResult<A, C->C? ,C?> {<br>
if let lhs = lhs {<br>
return .continue(lhs, { $0 })<br>
} else {<br>
assertionFailure()<br>
return .stop(nil)<br>
}<br>
}<br>
<br>
Use case 2 - Chaining on custom types<br>
<br>
And this especially may not be feasible and I may be out of my depth<br>
describing the requirement but it feels like a more general case so<br>
at least worth airing):<br>
<br>
It would be good for code like the following to be possible<br>
(hopefully with a little more type inference).<br>
<br>
let c:Either<Int, Error> = Either<String, Error>(.Left(“boo"))^^.count<br>
<br>
Now the user’s definition of the operator would probably have to<br>
look something like this:<br>
<br>
func ^^<A,B, C>(lhs: Either<A,B>)->(ChainValueResult<A, C,<br>
Either<C,B>> {<br>
switch lhs {<br>
case .Left(let a):<br>
return .continue(a, { Either<C,B>(.Left($0) })<br>
case .Right(let b):<br>
return .stop( Either<C, B>(.Right(b))<br>
}<br>
}<br>
<br>
I couldn't find any significant discussion of optional chaining in<br>
the mailing list so far.<br>
<br>
Joseph<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
--<br>
-- Howard.<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
<br>
<br>
-- <br>
Human Friendly Ltd.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br><br>-- <br> -- Howard.<br><br>