Why can’t you do this? No raw values required, except to initialize the enums.

struct Card {
    enum Suit : Int { case Hearts, Spades, Diamonds, Clubs }
    enum Rank : Int { case Ace, Two, Three, Four, Five, Six, Seven, Eight, 
Nine, Jack, Queen, King }

    let suit : Suit
    let rank : Rank

    init?(suit: Int, rank: Int) {
        guard let suit = Suit(rawValue: suit),
              let rank = Rank(rawValue: rank) else {
                return nil
        }
        self.suit = suit
        self.rank = rank
    }
}

let firstCard = Card(suit: 0, rank: 3)
let secondCard = Card(suit: 3, rank: 2)
firstCard?.rank // returns Four
secondCard?.suit // returns Clubs



> On Mar 24, 2016, at 11:18 AM, Carlos Rodríguez Domínguez via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Well, I propose the “#” syntax to be consistent with other proposals that 
> intend to provide compilation-related code. In this case, the proposal is 
> just a way to provide an indication that a certain field within a struct or 
> class should be enforced to be a value of a certain enum, not just a plain 
> integer, by the compiler. Anyhow, I think many different sintaxis could be 
> elaborated. For example, another possible syntax could imply reusing the 
> typealias expression:
> 
> extension Card{
>       typealias suit:CardSuit = suit:Int
> }
> 
> However, I assume that using this syntax it should be possible to directly 
> assign to the suit field both an integer or a CardSuit.
>> b

>> On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> It is a common practice in C to assign to integer (int, int16, int64, etc.) 
>> typed variables “constant" values declared in enums. In swift, it is in fact 
>> possible to do that by using enums' “rawValue” property. When importing 
>> structs from C into swift, we even get some fields declared with an integer 
>> type, but expecting the assignment of a “constant” declared inside an enum. 
>> Of course, this is error prone, it is “old-style” programming and very 
>> confusing for newcomers. To solve this issue, my proposal is to be able to 
>> create extensions that promote certain fields within a class or struct to 
>> enums.
>> 
>> For instance, let’s take these sample C struct and enum:
>> 
>> struct Card {
>>         int suit;
>>         int rank;
>> };
>> 
>> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>> 
>> (Note: I understand that above code follows a bad programming practice, yet 
>> it is widely common)
>> 
>> It should be imported into swift as follows:
>> 
>> struct Card {
>>         suit:Int
>>         value:Int
>> }
>> 
>> enum CardSuit : Int {
>>         case Hearts, Diamonds, Clubs, Spades
>> }
>> 
>> Now, I propose to be able to create an extension as follows:
>> 
>> extension Card {
>>         #enumvalue(suit:CardSuit)
>> }
>> 
>> From this moment on, the suit field should only receive CardSuit values, 
>> thus not requiring the use of raw values for assignments.
>> 
>> These extensions should also be of great interest for people using CoreData, 
>> since it is not possible to declare enums in models. Therefore, to declare 
>> enums, it is necessary to declare integer values, and then use the “unsafe”, 
>> “unexpressive" approach explained before.
>> 
>> Note that the proposal intends to only support promotions from integer 
>> values to enum values, but, for example, it could also be extended to string 
>> values.
>> 
>> Finally, it could be appropriate to extend this proposal to redeclare func’s 
>> signatures, in order to promote certain parameters to enum values.
>> 
>> Best,
>> 
>> Carlos.
>> _______________________________________________
>> 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
  • [swift-evolution] Promote... Carlos Rodríguez Domínguez via swift-evolution
    • Re: [swift-evolution... James Campbell via swift-evolution
      • Re: [swift-evolu... Carlos Rodríguez Domínguez via swift-evolution
        • Re: [swift-e... Paul Ossenbruggen via swift-evolution
          • Re: [swi... Carlos Rodríguez Domínguez via swift-evolution
            • [sw... Carlos Rodríguez Domínguez via swift-evolution
              • ... Andrey Tarantsov via swift-evolution
                • ... Carlos Rodríguez Domínguez via swift-evolution
              • ... Brent Royal-Gordon via swift-evolution
                • ... Carlos Rodriguez Dominguez via swift-evolution
                • ... Carlos Rodríguez Domínguez via swift-evolution
                • ... Brent Royal-Gordon via swift-evolution
                • ... Carlos Rodríguez Domínguez via swift-evolution
                • ... Goffredo Marocchi via swift-evolution

Reply via email to