> On Sep 17, 2017, at 7:55 AM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Sep 17, 2017, at 3:37 AM, Jonathan Hull via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> I run into use cases like this all the time…
>> 
>> I think I would prefer to see those concrete cases in a subtype though:
>> 
>>      enum DrinkSize {
>>              case small
>>              case medium
>>              case large
>>      }
>> 
>>      enum SummerDrinkSize : DrinkSize {
>>              //Inherits DrinkSize’s cases
>>              case extraLarge
>>      }
>> 
>> Because it is a subtype, you could place a SummerDrinkSize anywhere you can 
>> put a DrinkSize.  As a result, all switches on it would need a default case 
>> to handle cases they hadn’t planned for. If you mark an enum with “final” 
>> then it can’t be extended and switches can be exhaustive.
> 
> You have the subtype relationship backwards here.  DrinkSize is a subtype of 
> SummerDrinkSize.  All values of DrinkSize are also valid values of 
> SummerDrinkSize but not vice versa.  For this reason, inheritance syntax 
> doesn't make sense.  The syntax that makes more sense is some kind of case 
> embedding syntax:
> 
> enum SummerDrinkSize {
>               cases DrinkSize
>               case extraLarge
> }

I disagree.  I get that the shape of a DrinkSize would always fit in a 
SummerDrinkSize hole (ignoring the overriding/extension of methods), but the 
fact that we are requiring ‘default’ in switches changes the calculus.  
Basically, it changed when we decided to change whether exhaustive was the 
default.  The point is to make people consider that they may have cases which 
they may not expect.  That is much easier with a concrete idea of subtype, 
which people are already used to.


>> 
>> In addition to inheriting the cases, a subtype would also inherit, and be 
>> able to override, methods defined on the super-type.  You could use super to 
>> call the super-type’s implementation. 
> 
> I think implementation sharing is a bad idea for value types.  Value 
> subtyping should be conceptualized as a restricted mechanism for 
> value-preserving implicit conversion.

Why?


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to