Also IIRC, both of these limitations go away if you conform to RawRepresentable 
yourself.
  

  
There is no magic to RawRep. The compiler will just synthesise a failable 
initialiser and 'rawValue' computed property accessor. Both just simple switch 
statements matching your provided literals and returning the appropriate enum 
case.
  
 Specifically, RawRep does not change the raw representation of the enum. It's 
always going to be the smaller integer that fits the number of cases.
    
  
  
  

  
  
  
  

  
  
>   
> On Oct 4, 2016 at 6:56 pm,  <Karl Wagner (mailto:[email protected])>  wrote:
>   
>   
>   
>   
> Enum raw types don't have to be strings/integers, but they have to be 
> expressable by string or integer literals.   We don't guarantee uniqueness 
> per se, but we do check for duplicate literals and auto-increment integers to 
> fill gaps.
>   
>   
>
>   
>   
>   
>   
>
>   
> So all you have to do is make your custom type conform to 
> ExpressibleByStringLiteral and you can use it as an enum's raw type.
>   
>
>   
> Karl
>   
>   
> >   
> > On Oct 3, 2016 at 9:50 pm,  <Adrian Zubarev via swift-evolution 
> > (mailto:[email protected])>  wrote:
> >   
> >   
> >   
> >   
> >
> > Hi there,
> >
> >   
> >
> > I’m interested if this idea has some potential future in Swift or not.
> >
> >   
> >
> > Currently RawRepresentable enums accept only a subset of literal types like 
> > String, Character and the Integer family (enum Name : String { … }).
> >
> >   
> >
> > Sometimes this is not enough for my use-case and I wish I could feed my 
> > enums with other Hashable types!
> >
> >   
> >
> > As a workaround I can create a custom struct or even a class and conform it 
> > to  RawRepresentable  and fake an enum with some static variables (similar 
> > to what is done with  OptionSet  types).
> >
> >   
> >
> > The problem there is that I cannot use the same switch pattern matching 
> > like with enums. I’d wish either enums could accept Hashable types (maybe 
> > with some restriction) or the existence on a protocol to build custom 
> > enum-like types with strucs/classes and use the same switch pattern 
> > matching.
> >
> >   
> >   struct A : Hashable { /* implement everything */ } // Variant 1: enum 
> > Test : A { case something = A(rawValue: A(value: "something")) case nothing 
> > = A(rawValue: A(value: "nothing")) } // Variant 2: protocol SomeFancyName : 
> > RawRepresentable { … } struct Test : SomeFancyName { let rawValue: A 
> > init?(rawValue: A) { // Implement + reject unwanted `A`s } static let 
> > something = A(rawValue: A(value: "something")) static let nothing = 
> > A(rawValue: A(value: "nothing")) } let value = Test.something switch value 
> > { case .something: // handle case .nothing: // handle // Because of 
> > `SomeFancyName` the switch can use enum-like pattern matching + does not 
> > need the `default` case when all cases are present }    
> >   
> >
> >
> >
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >  --   
> >  Adrian Zubarev
> >  Sent with Airmail       
> >   
> >
> >
> >
> >   
> >  _______________________________________________ swift-evolution mailing 
> > list  [email protected] (mailto:[email protected])   
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >   
>   
>   
>   
>   
  
  
 
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to