<div dir="ltr">Default values and overloaded cases don't (and in fact, shouldn't) be conflated.<div><br></div><div>I support default values for associated values but I'm not yet ready to say I'm in favor of overloaded cases. There's no ambiguity because your Value.number example can't exist without overloads, and default values don't create parameter lists that could mismatch like that (there's still only one case, and it has all of the associated values regardless of how many you specify at the time you create it).</div><div><br></div><div>Small self-contained examples like Value are nice, but entirely hypothetical and a bit contrived. "Maybe the design of the API does not want something" is difficult to convince me—I'd prefer to see a significant real world situation where it's vital to have two cases with the same name with differently typed payloads, which can't be expressed in a different way. For example, in your Javascript example, I think the optionality of that Document would be far better expressed as an Optional<Document> with a default value of nil than creating an overload, and that solution introduces far less complexity to the language than would introducing arbitrary overloads.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 29, 2016 at 9:25 AM Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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"><div class="m_-539838249318647060bloop_markdown gmail_msg"><p class="gmail_msg">Don’t get me wrong, in my case default values with an optional will work just fine, but I don’t see how default values are better on associated types than:</p>
<pre class="gmail_msg"><code class="m_-539838249318647060swift gmail_msg">// default values
enum Something {
case a(String, Int? = nil, Int? = nil)
}
// vs.
enum Something {
case a(String)
case a(String, Int)
case a(String, Int, Int)
}
</code></pre>
<p class="gmail_msg">When the enum is public, do you want the user to check for all the optionals. This could be really pesky, if you ask me.</p>
<pre class="gmail_msg"><code class="m_-539838249318647060swift gmail_msg">if case a(let stringValue, .some(let firstInt), .some(let secondInt)) = … {}
// vs.
if case a(let stringValue, let firstInt, let secondInt) = … {}
</code></pre>
<p class="gmail_msg">How about this short example? How would you design an enum with default values? The idea here is to use the same enum case for number literals. Maybe the design of the API does not want something like <code class="gmail_msg">case int(Int)</code> and <code class="gmail_msg">case double(Double)</code> for any reasons.</p>
<pre class="gmail_msg"><code class="m_-539838249318647060swift gmail_msg">enum Value {
case string(String)
case number(Int)
case number(Double)
}
let intCase: Value = .number(1)
let doubleCase: Value = .number(2.0)
</code></pre>
<p class="gmail_msg"></p></div><div class="m_-539838249318647060bloop_original_html gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-539838249318647060bloop_original_html gmail_msg"><div id="m_-539838249318647060bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><br class="gmail_msg"></div> <br class="gmail_msg"> <div id="m_-539838249318647060bloop_sign_1480438884994848000" class="m_-539838249318647060bloop_sign gmail_msg"><div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">-- <br class="gmail_msg">Adrian Zubarev<br class="gmail_msg">Sent with Airmail</div></div> <br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-539838249318647060bloop_original_html gmail_msg"><p class="m_-539838249318647060airmail_on gmail_msg">Am 29. November 2016 um 17:45:07, Tony Allevato (<a href="mailto:allevato@google.com" class="gmail_msg" target="_blank">allevato@google.com</a>) schrieb:</p> <blockquote type="cite" class="m_-539838249318647060clean_bq gmail_msg"><span class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Tue, Nov 29, 2016 at 8:35 AM Adrian Zubarev
<<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</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">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_markdown gmail_msg">
<p class="gmail_msg">If we’re talking about non optional values
here, then I don’t produce a possible expensive copy of my
associated values (sure it depends on the type, COW etc.), but
that’s my main point for excluding the the associated values.</p>
</div>
</div>
</blockquote>
<div class="gmail_msg">Does matching against _ cause a copy to be made? I wouldn't
expect it to since it can never be used. If it does, I'd argue
that's a bug.</div>
<div class="gmail_msg"> </div>
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_markdown gmail_msg">
<p class="gmail_msg">Somewhere in my code I also have a semi schema
subscript which evaluates the enum case like this:</p>
<pre class="gmail_msg"><code class="m_-539838249318647060m_-5836122890542383372swift gmail_msg">if case .double = $0 { return true } else { return false }
</code></pre>
<p class="gmail_msg">There is just no better way for this check. I
wish I could write something like <code class="gmail_msg">return
.double ~= $0</code> there.</p>
</div>
</div>
</blockquote>
<div class="gmail_msg">We agree on this—I've had situations where I all I wanted to
know was whether an enum value matched a particular case, and a
Boolean case expression would be fantastic.</div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">
<div class="gmail_msg">Re: your earlier message, I'm trying to understand why you
want to avoid wrapping your types in optionals when, if you can
express both the presence and absence of them in an overloaded
case, that effectively means they *are* optional? Is there a
particular problem with Optional<T> that you're trying to
avoid? If you're already pattern matching to detect the enum case,
unwrapping the optional at the same time is no more difficult than
if it were non-optional.</div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">I'm not convinced that overloading enum cases is something
that should be supported, but I'm about 90% on supporting default
values. So I'm trying to understand why you want this specific
feature for your specific problem, and how it could apply
elsewhere.<br class="gmail_msg"></div>
<br class="m_-539838249318647060inbox-inbox-Apple-interchange-newline gmail_msg"></div>
<div class="gmail_msg"> </div>
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_markdown gmail_msg">
<p class="gmail_msg"></p>
</div>
<div class="m_-539838249318647060m_-5836122890542383372bloop_original_html gmail_msg">
</div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_original_html gmail_msg">
<div id="m_-539838249318647060m_-5836122890542383372bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><br class="gmail_msg"></div>
<br class="gmail_msg">
<div id="m_-539838249318647060m_-5836122890542383372bloop_sign_1480436917070613760" class="m_-539838249318647060m_-5836122890542383372bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">-- <br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</div>
</div>
<br class="gmail_msg"></div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_original_html gmail_msg">
<p class="m_-539838249318647060m_-5836122890542383372airmail_on gmail_msg">Am 29.
November 2016 um 17:19:16, Tony Allevato (<a href="mailto:allevato@google.com" class="gmail_msg" target="_blank">allevato@google.com</a>) schrieb:</p>
</div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_-539838249318647060m_-5836122890542383372bloop_original_html gmail_msg">
<blockquote type="cite" class="m_-539838249318647060m_-5836122890542383372clean_bq gmail_msg">
<div class="gmail_msg"><span class="gmail_msg"><span style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none" class="gmail_msg">I suppose I'm not seeing why it's important to
exclude the associated values from pattern matching. What do you
gain except saving a few characters?</span></span></div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div></div></span></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-539838249318647060bloop_original_html gmail_msg"></div><div class="m_-539838249318647060bloop_markdown gmail_msg"><p class="gmail_msg"></p></div></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" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>