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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
