[swift-evolution] Require parameter names for ENUM Associated Types?

[Tony Allevato]

Default values and overloaded cases don't (and in fact, shouldn't) be
conflated.

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).

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.


On Tue, Nov 29, 2016 at 9:25 AM Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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:
>
> // 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)
> }
>
> 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.
>
> if case a(let stringValue, .some(let firstInt), .some(let secondInt)) = … {}
>
> // vs.
>
> if case a(let stringValue, let firstInt, let secondInt) = … {}
>
> 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 case int(Int)
> and case double(Double) for any reasons.
>
> enum Value {
>
>     case string(String)
>     case number(Int)
>     case number(Double)
> }
>
> let intCase: Value = .number(1)
> let doubleCase: Value = .number(2.0)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 29. November 2016 um 17:45:07, Tony Allevato (allevato at google.com)
> schrieb:
>
>
>
> On Tue, Nov 29, 2016 at 8:35 AM Adrian Zubarev <
> adrian.zubarev at devandartist.com> wrote:
>
> 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.
>
> 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.
>
>
> Somewhere in my code I also have a semi schema subscript which evaluates
> the enum case like this:
>
> if case .double = $0 { return true } else { return false }
>
> There is just no better way for this check. I wish I could write something
> like return .double ~= $0 there.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 29. November 2016 um 17:19:16, Tony Allevato (allevato at google.com)
> schrieb:
>
> 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?
>
> _______________________________________________
> 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/20161129/898a6974/attachment.html>