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

[Adrian Zubarev]

Fair point, the more and more I’m thinking about default values, the more I’m convinced here.

And yes, as I mentioned before, default value would solve the problem in my API. I’m thinking of adapting the pitched idea so I almost get the right behaviour for free when Swift 4 drops.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. November 2016 um 04:32:17, Karl (razielim at gmail.com) schrieb:


On 29 Nov 2016, at 18:41, Tony Allevato via swift-evolution <swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161130/d321eb79/attachment.html>