> 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. Gwendal _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
