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

[Tony Allevato]

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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161129/933c8a07/attachment.html>