On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote:
> > > Le 3 août 2017 à 19:10, Itai Ferber <ifer...@apple.com> a écrit : > > > > I just mentioned this in my other email, but to point out here: the > reason this works in your case is because you adopt these methods as static > funcs and can reasonably rely on subclasses of NSData, NSNumber, NSString, > etc. to do the right thing because of work done behind the scenes in the > ObjC implementations of these classes (and because we’ve got established > subclassing requirements on these methods — all subclasses of these classes > are going to look approximately the same without doing anything crazy). > > > > This would not work for Codable in the general case, however, where > subclasses likely need to add additional storage, properties, encoded > representations, etc., without equivalent requirements, either via > additional protocols or conventions. > > Thaks for your explanation why a static method in a protocol is able to > instantiate non final classes like NSData, NSDate, NSNumber, > NSDecimalNumber, NSString, etc. > > Is this "privilege" stable? Can I rely on it to be maintained over time? > Or would it be a better idea to drop support for those low-level Foundation > classes, because they'll eventually become regular classes without any > specific support? This would not harm that much: Data, Date, String are > there for a reason. NSDecimalNumber is the only one of its kind, though. > Why not Decimal?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
