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

[Adrian Zubarev]

–1

We don’t have this behaviour with functions, so there is no need for that on enum cases. Something like this should be some point of the API Design Guideline instead.

Sometimes there is just no need for an extra label on an enum case with assocaited values.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. November 2016 um 14:11:55, Steve Prescott via swift-evolution (swift-evolution at swift.org) schrieb:

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 <swift-evolution at swift.org> 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 (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

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161130/c37e6f51/attachment.html>