[swift-evolution] Proposal: Stored properties for enums

[Matthew Johnson]

Chris,

Does this mean the compiler generated projection functions for labeled associated values that appear in every case are also out?  This proposal looks to me like pretty straightforward syntactic sugar for associated values that appear in every case.  

I understand if you want to avoid syntactic sugar for that in order to draw a stronger distinction between sum and product types but I don’t understand why it might be a good idea to provide compiler support for the projection functions but not sugar for streamlining the declaration of the associated values that should be present for every case.

Matthew

> On Dec 9, 2015, at 7:01 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Dec 9, 2015, at 12:28 PM, Jonathan Hise Kaldma via swift-evolution <swift-evolution at swift.org> wrote:
>> But it breaks down if you need to keep track of more data for each tree node, e.g. if you’re making a parser and need to keep track of source location. This could easily be solved with stored properties:
>> 
>> enum Expression {
>>   case Number(Double)
>>   case Variable(String)
>>   indirect case Unary(Operator, Expression)
>>   indirect case Binary(Operator, Expression, Expression)
>> 
>>   var location: Int = 0
>>   var length: Int = 0
>> }
> 
> The concern with doing this is that Swift currently distinguishes clearly between product & sum types, and this is a good thing.  With your proposal, there would be no difference between:
> 
> struct X {
>  var a, b : Int
> }
> 
> and:
> 
> enum X {
>  var a, b : Int
> }
> 
> As such, there would be no reason to have concepts in the language.  Some might argue that this is good (fewer things == better), but I’d argue that this is worse, because it can be better for clearly different things to be... different.
> 
> Further, Swift has a simple way to express this today use: an enum inside of a struct.  As far as I can tell, the only bad thing about this is that it breaks pattern matching over the recursive case.  However, this is a already an annoying aspect of swift’s current design that show up in other ways: for example, structs are generally more powerful than tuples, except that tuples can be pattern matched over.
> 
> IMO, the right way to fix this is to introduce the concept of pattern matching over structs and classes.  If you dig through history, you’ll see that Joe Groff implemented a sketch of this functionality in the compiler, but it was never fully baked so it was turned off before Swift 1.0, and eventually got removed.  A better baked out design and implementation could fix the problems you raise without causing a conflation between structs and enums.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution