As the original poster of this thread, I wanted to re-state the original question:
Should enums REQUIRE parameter names? Pro: The syntax would more closely match that for functions, which requires names for all parameters (unless you say “_”) vs. the current syntax that is sort of C-like. Con: More verbose With this suggestion, your declaration of a variable that uses an enum would resemble calling a function. e.g.: var myTeam = Team.football (name: “Redskins”, city: “Washington, DC”, quarterback: “Kirk Cousins”) > On Nov 30, 2016, at 5:14 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > 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 ([email protected] > <mailto:[email protected]>) schrieb: > >> >>> On 29 Nov 2016, at 18:41, Tony Allevato via swift-evolution >>> <[email protected] <mailto:[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
