<div dir="ltr">On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Le 3 août 2017 à 19:10, Itai Ferber <<a href="mailto:iferber@apple.com">iferber@apple.com</a>> a écrit :<br>
><br>
> 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).<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<br>
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.<br></blockquote><div> </div><div>Why not Decimal? </div></div><br></div></div>