[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Xiaodi Wu]

On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Le 3 août 2017 à 19:10, Itai Ferber <iferber at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/5ca0e79a/attachment.html>