My point would be to have a exact set of possible numerical cases. The issue with numerical cases is that they don’t have to be ordered and they could also be overlapping with other subsystems (by subsystem I mean a subsystem of your particular project).
Even if we had the ability to limit the range of numerical types like Int, we still might not be able to exclude inner values for that range, which makes RawRepresentable not quite efficient to work with. Numerical enum cases on the other hand could solve that issue elegantly. I see the reason for types other because of FP and integer literals, but I don’t see why we couldn’t have numerical enum cases. -- Adrian Zubarev Sent with Airmail Am 9. März 2017 um 08:52:34, Slava Pestov ([email protected]) schrieb: On Mar 8, 2017, at 11:46 PM, Adrian Zubarev <[email protected]> wrote: I don’t have more precise examples except something like TCP socket error codes as an enum. I would expect that the error code is available as a computed property of the enum value, perhaps as its raw value or something else. I would not expect it to be part of the enum case *name*. What significance does the numeric code have to the reader of the code, and when do you ever want to permanently freeze error codes in an API like this? Note that even Unix errno error codes are not standardized across unices or even different architectures running Linux; only their names are. Slava The example with the number literal is actually really good, because it also shows the bad sides of the pitch. However we could allow numerical enum cases without any issues right? -- Adrian Zubarev Sent with Airmail Am 9. März 2017 um 08:41:13, Slava Pestov ([email protected]) schrieb: On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution <[email protected]> wrote: I forget to mention, this should be also valid: let `42` = 42 print(`42`) struct A { let `0` = 0 } let number = A().0 -1 This seems really confusing. extension Int { var `0`: Int { return 0 } } 3.0 // is this a float literal? 3 .0 // member access? .0 // this is actually a contextual member access, and not a literal ‘0.0’? I’d prefer if .0, .1, … were reserved for tuple fields; .0 is already not very descriptive, but at the very least if you see it in source code you know you have a tuple type and not something else. Also the compiler’s name mangling relies on the fact that identifiers never begin with a numeric character or symbol. Can you give a motivating example where allowing an identifier to start with a number actually helps readability? Slava -- Adrian Zubarev Sent with Airmail Am 9. März 2017 um 08:24:54, Adrian Zubarev ([email protected]) schrieb: Hi Swift community, I’d like to pitch this idea again. Swift already has the pitched feature, but it is exclusive for tuples only. SE–0071 allowed the use of keywords after the . in a member access, except for those keywords that have special meaning by using back-ticks. However, members starting with numbers are not special keywords and as already mentioned, numerical members are already allowed in tuples. I propose to extend that capability to the whole language and make that behavior consistent. To disambiguate members starting with a number one would need to use back-ticks. // Enum enum ErrorCode : String { case `2345` = "my description for 2345" case `123a` = "my description for 123a" case `123b` = "my description for 123b" } let code = ErrorCode.2345 // Function func `42foo`(label: Type, `12345`: Type, `0987something`: Type) { … } // Tuple (`1`: Int, `2`: Int) My question is: would that be in scope for Swift 4? -- Adrian Zubarev Sent with Airmail _______________________________________________ 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
