> I think it's best to keep this thread focused on classes. We can start a new
> thread for methods later if desired. But we should wait until the dust has
> settled on the classes conversation IMO.
I disagree: The whole thread is not about practical implications but rather
about general standpoints, so the discussion will be identical — and I foresee
that this second thread would start with "now that we made classes final by
default, it's just natural consequence to do the same with methods".
>> Making `final` the default, or `sealed` the default, encourages the use of
>> closed class hierarchies. It attempts to make inflexibility the preferred
>> form of shared Swift code. I'm not sure that's the right thing to do.
>>
> I don't agree with this framing. IMO it encourages alternative designs
> emphasizing protocols and composition. This is a very good thing IMHO. I
> like to think of inheritance is a tool is last resort.
The claim about inflexibility is to take with a grain of salt, but why do you
think it is good to force your opinion on how flexibility should be achieved on
others? Protocols and composition are useful without breaking inheritance, just
leave the choice to the people.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
