[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