> On Jul 16, 2016, at 9:18 AM, Taras Zakharko <[email protected]> wrote: > > >> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I agree with Kevin Ballard on being open by default for methods/ properties >> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ >> <http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/> >> >> If we are open by default for methods/properties then we could simplify >> things by just using final for methods that need to be sealed; I don’t see >> the need to have sealed methods/properties outside of the module ONLY. > > The proposal (and additional comments) explain this point fairly well. > Usually, it makes sense to be overridable only for few select members — and > compiler can’t easily figure out which entry points these are as the API > invariants are not explicit. By making members sealed by default, the API > contracts are made more clear. Second (and a very important reason) is > performance — if everything is open by default, the compiler can’t > devirtualize property accessors even though it would be appropriate most of > the time. The compiler can infer the ‚final‘ status of definitions within a > module easily and optimise accordingly, which wot work if these definitions > can be overridden externally. To put it differently, its much easier for the > compiler to determine what can be safely considered final than what can be > safely considered sealed. The design choices in the proposal follow naturally > from these considerations.
The compiler is welcome to optimize my sealed classes but once I slap `open` on the class, I am telling the compiler that I am not interested in the automatic optimizations imo. > > The final keyword still has its use, although I think its utility will be > somewhat diminished after this proposal. You can still use it for things that > can’t be overridden internally. Like classes that are intended only to be > used as ‚structs with reference semantics’. struct with reference semantics is what sealed classes are, but once I make the class open, i’d like for it to act like a regular subclassable class. > > — T > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
