> On 29 Nov 2016, at 18:41, Tony Allevato via swift-evolution
> <[email protected]> wrote:
>
> 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.
Yeah, we shouldn’t confuse these issues. Default values for enum payloads are
something I also really want (in Swift 4 phase 2). Here’s my use-case:
public enum ReadError : Error {
case otherError(description: String, location: StaticString? = #function)
// <- currently an error, tuples can't have default values
}
And yes, you can use #function as a default value:
func doIt(_ str: String = #function) {
print("Called from \(str)")
}
func myFunc() { doIt() }
doIt() // Prints “Called from __lldb_expr_1” in REPL
myFunc() // Prints “Called from myFunc()”
I think that’s a more valuable use-case than overloaded values; so if they’re
incompatible and we have to choose one, I’d go for default values.
- Karl_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
