> On Mar 8, 2017, at 11:46 PM, Adrian Zubarev <adrian.zuba...@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 (spes...@apple.com > <mailto:spes...@apple.com>) schrieb: > >> >>> On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.zuba...@devandartist.com <mailto:adrian.zuba...@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 >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
