[swift-evolution] Promote "primitive" types to enums in extensions

Paul Ossenbruggen possen at gmail.com
Fri Mar 25 00:42:09 CDT 2016


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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/f53c11fe/attachment-0001.html>


More information about the swift-evolution mailing list