[swift-evolution] Proposal: Pattern Matching Partial Function (#111)
David Owens II
david at owensd.io
Wed Feb 3 00:39:28 CST 2016
I'm really confused by this proposal. Primarily it really seems to be asking for two things:
1. Allow closures to skip the "switch item" line, and
2. Implicit returns within closures
The desired troy example:
let weightKg = weightTroy.reduce(0.00) {
case (let acc, Troy.Pound(let quantity)): acc + Double(quantity) * 0.373
case (let acc, Troy.Ounce(let quantity)): acc + Double(quantity) * 0.031103
case (let acc, Troy.Pennyweight(let quantity)): acc + Double(quantity) * 0.001555
case (let acc, Troy.Grain(let quantity)): acc + Double(quantity) * 0.0000648
}
What you can already do today:
let weightKg = weightTroy.reduce(0.00) { acc, troy in
switch troy {
case let .Pound(quantity): return acc + Double(quantity) * 0.373
case let .Ounce(quantity): return acc + Double(quantity) * 0.031103
case let .Pennyweight(quantity): return acc + Double(quantity) * 0.001555
case let .Grain(quantity): return acc + Double(quantity) * 0.0000648
}
}
Unless I'm misunderstanding some other great value, this seems like a lot of syntax to save typing "switch troy" and "return". If you forget "return", the compiler will already error for you. I don't think the desired example brings more clarity either.
As to the initialization example:
let str: String = {
switch($0) {
case .Cold: return "Too cold"
case .Hot: return "Too hot"
default: return "Just right"
}
}(state)
Yes, the type must be explicit because Swift cannot figure it out. I'd rather address that issue.
For me, I'm really not seeing the value the complexity of the proposal brings.
-David
> On Feb 2, 2016, at 10:07 PM, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
>
> I will wait another 24 hours before resubmitting it (even though this discussion thread is not long)….
>
> Anyone that had commented on this in the other thread, but not this one — it would be greatly appreciated if at least one comment (yay or nay) were added to this thread.
>
> I think the last thread where this was discussed for at least 10 days and had many more comments - already fleshed everything out.
>
>
>> On 2016-02-03, at 13:03:18, Paul Ossenbruggen <possen at gmail.com <mailto:possen at gmail.com>> wrote:
>>
>> Agreed. I really would like this to move forward.
>>
>>
>>> On Feb 2, 2016, at 6:59 PM, Denis Nikitenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> +1 from me - I would like to see this discussion continue. Swift already recognizes the utility of pattern matching for initialization by retaining the ?: operator. It would be nice to see a more general and flexible solution that is still reasonably concise and doesn’t introduce new keywords and operators - though I’m sure at least some changes to the language would be inevitable.
>>>
>>>
>>>> On Jan 29, 2016, at 1:43 AM, Craig Cruden via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>> The following proposal apparently was not considered widely enough discussed since it was “buried” in a 400 message discussion thread that meandered before coming to the final draft.
>>>>
>>>> As such, to have it reopened — I am restarting the discussion in a new thread to ensure wider discussion.
>>>>
>>>>
>>>> https://github.com/cacruden/swift-evolution/blob/master/proposals/0024-Pattern-Matching-Partial-Function.md <https://github.com/cacruden/swift-evolution/blob/master/proposals/0024-Pattern-Matching-Partial-Function.md>
>>>>
>>>>
>>>> Pattern Matching Partial Function
>>>>
>>>
>>> <snip>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160202/082c1aec/attachment.html>
More information about the swift-evolution
mailing list