I already said it, I don’t want to wrap my types into optionals when there is
no need for that.
Plus what’s the need of default values in associated enum cases anyways? Just
assume for a second that we could overload enum cases:
enum MyEnum {
case a(Int)
case a(Int, b: Int = 42)
}
let myEnumValue = MyEnum.a(0) // What will this produce? Or should we write
`MyEnum.a(0, b:)` which is ugly from my point of view
However I see where this might work, but again, what’s the use case here?
enum MyEnum {
case a(Int)
case a(Int = 42, b: Int)
}
let a1 = MyEnum.a(0)
let a2 = MyEnum.a(b: 0)
--
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? What
you're suggesting doesn't strike me as a significant improvement over this:
```
case javascript(String, scope: Document?)
...
switch self {
case .javascript(_, scope: .none): return 0x0D
case . return 0x0F // or case .javascript(_, scope: .some), if you want to
be explicit about the distinction between the two cases
}
```
On Tue, Nov 29, 2016 at 8:12 AM Adrian Zubarev
<[email protected]> wrote:
As I said before, the associated values can be excluded for pattern matching. I
believe this way you can check against the enum case without producing any copy
of the associated types right?!
var _kind: Byte {
switch self {
…
case .javaScript: return 0x0D
case .scopedJavaScript: return 0x0F
…
}
}
Assume we could overload the values by including additional labels to the enum
case.
case javaScript(String)
case javaScript(String, scope: Document) // or more swifty `javascript(String,
withScope: Document)`
Now I could check the case like this to solve the ambiguity.
switch self {
…
case .javaScript: return 0x0D
case .javaScript(_:withScope:): return 0x0F
…
}
Plus I don’t want to wrap values in optionals when there is no need for that.
--
Adrian Zubarev
Sent with Airmail
Am 29. November 2016 um 17:03:12, Tony Allevato ([email protected]) schrieb:
Why not:
```
case javascript(String, scope: Document?)
```
Your desired scenario looks like it's conceptually expressing that Document is
optional, so why not use the type to codify that?
On Tue, Nov 29, 2016 at 7:59 AM Adrian Zubarev via swift-evolution
<[email protected]> wrote:
Hmm, I feel like default values wouldn’t work with overloaded enum cases.
In my own project I have something like this:
case javaScript(String)
case scopedJavaScript(String, scope: Document)
// But I'd like it to be:
case javaScript(String)
case javaScript(String, scope: Document)
--
Adrian Zubarev
Sent with Airmail
Am 29. November 2016 um 16:55:52, Charles Srstka ([email protected])
schrieb:
On Nov 29, 2016, at 9:52 AM, Adrian Zubarev via swift-evolution
<[email protected]> wrote:
I just showed a direction of what could be possible.
Personally I think it would be enough if we had this:
enum MyEnum {
case a
case b(Int)
case b(Int, string: String)
}
Where .b can be overloaded by it’s associated types.
Or default values:
enum MyEnum {
case a
case b(Int, string: String = “SomeDefault”)
}
Charles
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
