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 ([email protected]) schrieb:
On Tue, Nov 29, 2016 at 8:35 AM Adrian Zubarev
<[email protected]> 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 ([email protected]) 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
