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

[Carlos Rodríguez Domínguez]

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 <possen at 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 at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160325/c3510d76/attachment.html>