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
