[swift-evolution] ternary operator ?: suggestion
Maximilian Hünenberger
m.huenenberger at me.com
Tue Jan 19 15:14:14 CST 2016
That was also my concern. Where `map` is used to map the elements of a collection and one which maps the whole value.
I'm in favor of adding `match` as a method.
Particularly there could be a `Matchable` protocol which requires the pattern match operator function (`~=`) and as default implementation you get a `match` method.
- Maximilian
> Am 19.01.2016 um 21:47 schrieb Thorsten Seitz via swift-evolution <swift-evolution at swift.org>:
>
>
>> Am 19.01.2016 um 20:50 schrieb Paul Ossenbruggen <possen at gmail.com>:
>>
>> I am not following why it is not good to add map to basic types. Aren't we mapping values?
>
> We do, but for the pattern matching case we want to map all types not just basic types and in case of collections we would want to match the whole collection, e.g. against a range.
>
> match(collection) {
> case [1,2,3]: ...
> default: …
> }
>
> is something else than
>
> collection.map {
> case 1: …
> default: …
> }
>
> where we match each element and return a collection.
>
> I’d rather make the matching as „switch-expression“ stand out a little bit.
>
> -Thorsten
>
>
>>
>> Also, Craig I was thinking I might have a few tweaks do you mind if I do a pull request or would you prefer email feedback?
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Jan 19, 2016, at 10:55 AM, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> Thorsten,
>>>
>>> I made the changes you suggested with regards to match
>>>
>>> Can you double check to make sure I did not make any stupid mistakes?
>>>
>>>
>>>>> On 2016-01-20, at 1:03:16, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>>>>>
>>>>>
>>>>> Am 19.01.2016 um 06:28 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org>:
>>>>>
>>>>> If you extend the same analogy to switch, then the most important cases are when the pattern being matched and the values being processed are lexically small, and have few cases. We have a lot of syntactic sugar for processing optionals (e.g. if/let, the ?? operator, etc), but ?? for example doesn’t apply to general pattern matching. With the expression above, for example, you could match on an enum analogously to the ?? operator like this:
>>>>>
>>>>> result = someEnum ? case .SomeCase(let x): x, default: y
>>>>>
>>>>> If you compare that to a switch statement, I can see how that could be compelling. OTOH, the larger the expression (the more cases) and the more complex the patterns, the better a switch statement starts to look.
>>>>
>>>> For me the killer feature is not being able to write it inline, it is making it clear that an assignment happens, i.e.
>>>>
>>>> let result = someEnum ?
>>>> case .SomeCase(let x): x
>>>> default: y
>>>>
>>>> is IMO much more readable (= allowing to instantly see what’s going on) than
>>>>
>>>> let result
>>>> switch someEnum {
>>>> case .SomeCase(let x): result = x
>>>> default: result = y
>>>> }
>>>>
>>>> The first one makes the variable which is assigned stand out because the rest is indented and the equals sign is prominently visible.
>>>> The latter version is just a large heap of tokens hiding some assignments :-)
>>>>
>>>> For the same reason
>>>>
>>>> let result = match(someEnum) {
>>>> case .SomeCase(let x): x
>>>> default: y
>>>> }
>>>>
>>>> would be just as appealing to me. For using this as a switch-expression I’m strongly against introducing a special map method for basic types, though and rather propose to use a global function „match“ (more on that further below).
>>>>
>>>> The inline version (if desired) is not too different from the ?-based switch-expression:
>>>>
>>>> let result = match(someEnum) { case .SomeCase(let x): x; default: y }
>>>>
>>>>
>>>>
>>>> The big advantage of the partial function proposal would be that it is much more general as it is usable everywhere a unary function argument is used, i.e. for map etc.
>>>> With the ?-based switch-expression I would have to write
>>>>
>>>> let result: [Int] = collection.map { element in element ?
>>>> case .SomeCase(let x): x
>>>> default: y
>>>> }
>>>>
>>>> That is not too bad but requires the boilerplate of having to introduce a name which is instantly consumed and not used anywhere else.
>>>> Admittedly there might be cases (no pun intended) where this might be useful, though, like
>>>>
>>>> let result: [SomeEnum] = collection.map { element in element ?
>>>> case .SomeCase(let x) where x > 5: element
>>>> default: .OtherCase
>>>> }
>>>>
>>>> Hmmm. Would this use case be common enough to make this version using a ?-based switch-expression be preferable over the partial function syntax?
>>>>
>>>>
>>>>
>>>> As I already said above I’m strongly against introducing a map function for basic types. This brings confusion to the notion of a partial function and to what a map function is and is not needed IMO.
>>>>
>>>> Just define the following global function:
>>>>
>>>> func match<T,U>(x: T, @noescape mapping: T -> U) -> U {
>>>> return mapping(x)
>>>> }
>>>>
>>>> That’s all that is needed. Except for the case-expression shorthand, of course :-)
>>>>
>>>>
>>>>
>>>> Without that proposed shorthand („partial function“) I currently have to write
>>>>
>>>> let result = match(someEnum) { (arg: Foo) -> Int in
>>>> switch arg {
>>>> case .SomeCase(let x): return x
>>>> default: return 42
>>>> }
>>>> }
>>>>
>>>> instead of the equivalent
>>>>
>>>> let result = match(someEnum) {
>>>> case .SomeCase(let x): return x
>>>> default: return 42
>>>> }
>>>>
>>>> as proposed (with the added change of using match instead of map).
>>>>
>>>>
>>>> -Thorsten
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160119/786e9163/attachment.html>
More information about the swift-evolution
mailing list