Le 23 déc. 2015 à 13:36, Matthew Johnson <matt...@anandabits.com> a écrit : > >> I'm not sure why you say the last two should be addressed separately from >> the "production" language. Are you proposing Swift should come in multiple >> language variants? >> > > Not exactly. > > My point is that it is best to design the language to address production > concerns first. If the defaults in that design cause problems for > prototyping and / or education it is possible to offer an environment with a > modified default. I don’t know if that is a good idea or not. I am not a > target user for either of those use cases (personally, I would rather > prototype with the production language). Either way, it is possible, just as > it is possible to have @testable to facilitate unit testing. > > I strongly feel that I shouldn’t pay a price in production code in order to > better support those use cases. IMO ‘final’ is the right default for > production code and we pay a price if the default is anything less, including > ‘sealed’.
By "pay a price" you mean diminished performance, right? That would depend on the ABI (which hasn't been discussed much yet, is there some preliminary docs about it?). I don't think there is a price in performance to pay for sealed. You simply call a static function in the library, and that static function does the dynamic dispatch only if the library contains some overrides for that function. If there's no override it's simply purely a static call. -- Michel Fortin https://michelf.ca
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
