I could see a purpose for identifiers which started numbers but weren't
entirely numerical.
e.g.
enum Dimensions { case `2D`, `3D` }
enum DiceRoll { case d6, `2d6` }
func roll(dice: DiceRoll) -> Int { ... }
roll(.`2d6`)I'm not sure I see one for identifiers which are entirely numerical. Ross On Thu, Mar 9, 2017 at 8:05 AM, Adrian Zubarev via swift-evolution < [email protected]> wrote: > 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 <adrian.zubarev@devandartist. > com> 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 (adrian.zubarev@devandartist. > com) 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
