Re: [swift-evolution] Optional Argument Chaining

+1 -Thorsten > Am 18.12.2017 um 08:42 schrieb Elviro Rocca via swift-evolution > : > > While it's definitely worth knowing, it's not a really usable substitute for > higher-kinded types in production code, and still requires a lot of code > generation, which is eased in Kotlin thanks to its a

Re: [swift-evolution] Optional Argument Chaining

While it's definitely worth knowing, it's not a really usable substitute for higher-kinded types in production code, and still requires a lot of code generation, which is eased in Kotlin thanks to its annotation/metaprogramming features. Event the Kategory people recognized that the emulation a

Re: [swift-evolution] Optional Argument Chaining

Sent from my iPad On Dec 13, 2017, at 11:13 PM, Stephen Celis wrote: >> On Dec 13, 2017, at 9:53 PM, Erica Sadun wrote: >> >> Chris L had a beautiful solution for an "Unwrappable" protocol that allowed >> all of the optional sugar to be extended to any type that had a biased >> `Wrapped` i

Re: [swift-evolution] Optional Argument Chaining

I do not feel new syntax is needed for this. You can do this currently: postfix operator ¿ extension Optional { struct UnwrapError: Error {} static postfix func ¿(_ value: Optional) throws -> Wrapped { if let value = value { return value } else { th

Re: [swift-evolution] Optional Argument Chaining

> On Dec 13, 2017, at 9:53 PM, Erica Sadun wrote: > > Chris L had a beautiful solution for an "Unwrappable" protocol that allowed > all of the optional sugar to be extended to any type that had a biased > `Wrapped` item, allowing it to be used with `Either`, `Wrapped`, etc as well > as form th

Re: [swift-evolution] Optional Argument Chaining

> On Dec 13, 2017, at 10:20 AM, Stephen Celis via swift-evolution > wrote: > >> On Dec 11, 2017, at 1:08 PM, Matthew Johnson via swift-evolution >> wrote: >> >> It’s worth mentioning that the problem this thread is discussing can be >> generalized to idioms / applicative. The specific cas

Re: [swift-evolution] Optional Argument Chaining

> On Dec 11, 2017, at 1:08 PM, Matthew Johnson via swift-evolution > wrote: > > It’s worth mentioning that the problem this thread is discussing can be > generalized to idioms / applicative. The specific case here is for Optional > but many other types could benefit from an elegant syntactic

Re: [swift-evolution] Optional Argument Chaining

+1 to this. I also like Adrian’s notation where the ? is after the name, but before the parameter list. > On Dec 12, 2017, at 7:33 AM, Yuta Koshizawa via swift-evolution > wrote: > > I think evaluating them in the same way as `try` calls is consistent. > > ``` > f(g()?, h()?, i(), j()?)? > /

[swift-evolution] Optional Argument Chaining

Hi all, We probably don't need additional syntax to achieve this. I just wrote a library which allows you to `(pass?.aLongOptionalChaining()?.to ?< aFunctionTakingNonOptionalValues(:))?.ThenDoSomethingElse()` with `?>` operator. The multiple parameters example: (john.address, alice.address, 2.

Re: [swift-evolution] Optional Argument Chaining

That’s actually the cool part of merging optional func infix ? with the discussed problem. If you think how we could represent optional func in pure swift only with some sugar (and also the ability to write var function(label:label:) which we’ll get at some point) then we could do this: protoco

Re: [swift-evolution] Optional Argument Chaining

In addition to being unspecific, how would you access an optional closure? Since trailing operators can’t be separated with whitespace, how do you differentiate two trailing “?” from a “??” operator? i.e. let a:Int? = ... let b:Int? = ... let someFunction:((Int, Int)->(Int))? = ... let c = so

Re: [swift-evolution] Optional Argument Chaining

I propose that we do not add a suffix ? to the arguments because it does not really signal that the whole function may return an optional value. This is especially not convenient in a nested scenario like mentioned by others in previous posts. Instead we should reuse the inifix ? on functions, s

Re: [swift-evolution] Optional Argument Chaining

Even this small example I think this is still a little fiddly. If we add another required parameter to the Markdown initializer: let readme = String(contentsOfFile: “README.md”).flatMap { Markdown(string: $0, flavor: .github) } this starts to feel a little inside-out and crufty to me. >

Re: [swift-evolution] Optional Argument Chaining

I’d agree with that. That’s consistent with the “left-to-right and short-circuit at first failure” approach. > On 12 Dec 2017, at 15:33, Yuta Koshizawa wrote: > > I think evaluating them in the same way as `try` calls is consistent. > > ``` > f(g()?, h()?, i(), j()?)? > // like > try f(try g()

Re: [swift-evolution] Optional Argument Chaining

I think evaluating them in the same way as `try` calls is consistent. ``` f(g()?, h()?, i(), j()?)? // like try f(try g(), try h(), i(), try j()) ``` ``` foo(bar(x()?)) + y()? // like foo(bar(try x())) + (try y()) ``` -- Yuta 2017-12-12 7:42 GMT+09:00 Slava Pestov via swift-evolution : > > > O

Re: [swift-evolution] Optional Argument Chaining

In my opinion, simple left to right evaluation where it short circuits on the first failure is the simplest. But I don’t think it matters that much as long as we have a consistent way to define it, and explain it. It is nice to have forward transfer from other features, but sometimes we just n

Re: [swift-evolution] Optional Argument Chaining

I think it might be a good idea to reuse optional function syntax in this case. I don’t think it would even break existing code with the rule I described in my previous post. I mean, in the end the result of the whole function becomes optional (only if it was non-optional before, or it simply st

Re: [swift-evolution] Optional Argument Chaining

To me the short syntax should be a ‘macro’ expansion (syntax sugar only), therefore option 1 in Nick’s example. I choose the syntax sugar option because it is easy to explain. -- Howard. > On 12 Dec 2017, at 7:03 pm, Nick Keets via swift-evolution > wrote: > > > >> On Tue, Dec 12, 2017 a

Re: [swift-evolution] Optional Argument Chaining

On Tue, Dec 12, 2017 at 12:42 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > I think it gets confusing when you have multiple levels of nested > expressions, eg > > foo(bar(x?)) + y? > > Slava > I'm not sure we need to optimize much for complicated nested examples, a

Re: [swift-evolution] Optional Argument Chaining

You talk about flatMap without giving an example. The readme isn't that bad with it, IMO: if let readme = String(contentsOfFile: "README.md").flatMap(Markdown) { // use contents here } That doesn't work when you need multiple optional parameters. In my own experience, that hasn't been a

Re: [swift-evolution] Optional Argument Chaining

i’ve run into this problem enough to wish this was a thing in Swift a lot, but when it comes to solutions, i think the proposed syntax just isn’t clear or easy to read, especially if there’s multiple layers involved. On Mon, Dec 11, 2017 at 1:28 PM, Xiaodi Wu via swift-evolution < swift-evolution@

Re: [swift-evolution] Optional Argument Chaining

> On Dec 11, 2017, at 2:41 PM, Jared Khan via swift-evolution > wrote: > > I missed the previous threads! I’ve found one of the relevant threads here: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024201.html > >

Re: [swift-evolution] Optional Argument Chaining

I missed the previous threads! I’ve found one of the relevant threads here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024201.html Thanks for this important point. If you were to wri

Re: [swift-evolution] Optional Argument Chaining

I missed the previous threads! I’ve found one of the relevant threads here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024201.html Thanks for this important point. If you were to wri

Re: [swift-evolution] Optional Argument Chaining

This is an interesting example but I think the solution might be simple if we try to desugar it. // example f(g()?, h()?, i(), j()?)? // desugared let/var someF: SomeType? if let someG = g(), let someH = h(), let someJ = j() { someF = f(someG, someH, i(), someJ) } else { someF = nil } F

Re: [swift-evolution] Optional Argument Chaining

This topic has been discussed at least two and maybe more times in the past. It’s hard for me to post links at the moment, but it should be possible to find on Google. One major challenge to this idea, for which no satisfactory answer has been achieved after all these years, is the following issue

Re: [swift-evolution] Optional Argument Chaining

> 12 Dec. 2017 02:58 Jared Khan wrote: > > 2. It felt natural to me. It’s analogous to the existing optional chaining > scenarios and composes nicely. I think it’s about as understandable as > existing chaining, a newbie would have to look it up to discover its meaning. > What are your though

Re: [swift-evolution] Optional Argument Chaining

It’s worth mentioning that the problem this thread is discussing can be generalized to idioms / applicative. The specific case here is for Optional but many other types could benefit from an elegant syntactic solution to this problem. It might be worth exploring a more general solution. Here’

Re: [swift-evolution] Optional Argument Chaining

1. Correct 2. It felt natural to me. It’s analogous to the existing optional chaining scenarios and composes nicely. I think it’s about as understandable as existing chaining, a newbie would have to look it up to discover its meaning. What are your thoughts on this particular syntax (ignoring 3

Re: [swift-evolution] Optional Argument Chaining

I don’t think that solves the same thing. The problem is I read it is to allow some sort of short hand to be able to pass optional types as parameters into methods / initializers that do not take optional types. The result of that method / initializer being nil if any of said parameters were n

Re: [swift-evolution] Optional Argument Chaining

You can create a binary operator that tests the left-hand operand for nil, and passes the unwrapped value to the right-hand operand (a function taking one value), this operator can be made left-associative to allow chaining. let m = String(contentsOfFile: "README.md") ??? Markdown where ??? is

Re: [swift-evolution] Optional Argument Chaining

> 12 Dec. 2017 01:30 Jared Khan via swift-evolution > wrote: > > I'd like to propose a syntax addition that acts to ease some things that I > believe should fall under the umbrella of 'optional chaining'. Optional > chaining allows us to access the properties of an optional value and return

[swift-evolution] Optional Argument Chaining

Hi all, I'd like to propose a syntax addition that acts to ease some things that I believe should fall under the umbrella of 'optional chaining'. Optional chaining allows us to access the properties of an optional value and return nil if any link in that chain breaks. I propose we introduce syn