<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I can see it two different ways: 1) this is optional syntax, and doesn't replace or deprecate any existing syntax, so if you want to use it you have to have a label for the associated value, or 2) you may omit the label if you never reference the associated value within any of the calculated fields inside the case block.</div><div class=""><br class=""></div><div class="">That's perhaps a bit harsh, so I'm open to other ideas. I'm mostly concerned with keeping the proposal simple enough to be a "hidden switch" statement so that it doesn't grow too large or complicated, but I recognize that perhaps I'm erring more on the conservative side than necessary here. :-)</div><div class=""><br class=""></div><div class="">—Tim</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 9, 2017, at 2:11 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Ah, my apologies—the syntax highlighting in the thread was throwing off my e-mail client and I was having trouble reading it.<div class=""><br class=""></div><div class="">Associated values don't necessarily have to have names: I can write "case .foo(Int)". Since your examples use the associated value label as the name of the value inside the body, how would you handle those label-less values?</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jan 9, 2017 at 1:06 PM Tim Shadel <<a href="mailto:timshadel@gmail.com" class="">timshadel@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">There are examples of associated values in the proposed syntax. Which parts should I provide more detail on?</div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Jan 9, 2017, at 1:43 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_-1324931357276940503Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">While I do like the consolidated syntax more than most of the alternatives I've seen to address this problem, any proposed solution also needs to address how it would work with cases that have associated values. That complicates the syntax somewhat.<div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Jan 9, 2017 at 12:37 PM Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Enums get large, and they get complicated because the code for each case gets sliced up and scattered across many functions. It becomes a "one of these things is not like the other" situation because writing functions inside enums is unlike writing functions in any other part of Swift code.<br class="gmail_msg">
><br class="gmail_msg">
> The problem I see with this is that enums and their functions inherently multiply each other. If I have 3 cases and 3 functions or properties, there are 9 implementation details, no matter how they're organized. There can be 3 functions/properties, each with a 3-case switch, or there can be 3 enum cases each with 3 strange, partial functions/properties.<br class="gmail_msg">
><br class="gmail_msg">
> I can see why someone might prefer one over the other, but is either way truly better? The current way this works at least has the merit of not requiring a special dialect for enums.<br class="gmail_msg">
<br class="gmail_msg">
I’m not sure how to argue this, but I feel pretty strongly that something more like this proposed organization *is* actually better. That said, I do not think this conflicts with the current design of enums, however, so this is likely purely additive. The current design makes some situations almost comically verbose and disorganized, IMO, but it *is* right for other situations. We may want to have both.<br class="gmail_msg">
<br class="gmail_msg">
l8r<br class="gmail_msg">
Sean<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>