The key of this proposal is that the struct/class should come from outside any swift source code, that is, either imported by the compiler from C, or auto-generated from any external tool (i.e., a CoreData autogenerated class from a graphically specified data model). Of course, in well written structures (as specified by Paul Ossenbruggen) we shouldn’t have any need for this proposal. However, many C structures make use of a raw type instead of an enum type, but specifying (through the associated documentation, not by any type enforcement) that only a set of enum values are allowed. Consequently, the resulting code making use of those structures becomes highly error prone, and, particularly in swift, very “old-style” code and difficult to understand for newcomers.
Again, I would like to highlight that my proposal intends to avoid as much as possible the use of enums’ raw values. > El 25 mar 2016, a las 6:42, Paul Ossenbruggen <pos...@gmail.com> escribió: > > 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 <mailto: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 <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