To loosely bring my comment from SR-5122 over — Codable just performs codegen; there's nothing it can do that you can't write yourself, and vice versa. Making this work for Codable specifically would require us to special-case this through several layers of the compiler, I think.

But, at the very least, I think that we can improve the diagnostic to make it clearer what's going on. Yes, you will still have to manually implement init(from🙂 (which you would have had to do anyway in order to encode/decode the additional properties you're adding), but it would be clearer why if we produced something like "note: subclass initializer 'init(prop: String)' prevented inheritance of 'required init()'; 'required init()' must be overridden".

@belkadan Any thoughts?

FWIW, even if Subclass did inherit init(from🙂, I think it would still be pretty confusing as prop wouldn't ever get encoded or decoded (since the implementation is being inherited). This is a problem that we have today that we need to properly diagnose somehow.

I still think it's a trap that init(from:) can be inherited in the first place; I agree that we would at least want a warning when you did that. To me, that means special-casing this diagnostic makes sense as well.

I really wish we could ask for synthesis somehow.

Just to emphasize the point once again: it's not like you and I don't know how to write init(from:) by hand. The problem is that a beginner doesn't know. We've led everyone down this wonderful garden path where you just adopt Codable and everything just works automagically with no code, and then the path turns out to lead into a nest of thorns just because something is subclassed somewhere. That's what happened to the OP in the Stack Overflow question.

This could be a product of the same problem: https://stackoverflow.com/questions/48566443/implementing-codable-for-uicolor The OP expected to be able to make UIColor Codable but couldn't.

@mattneub That's a different issue — you can't add required initializers in extensions to non-final classes:

import Foundation

extension NSString: Decodable {
    public required init(from decoder: Decoder) throws {
        self.init(string: "Hello!")
    }
}

produces

Untitled 2.swift:4:21: error: designated initializer cannot be declared in an extension of 'NSString'; did you mean this to be a convenience initializer?
    public required init(from decoder: Decoder) throws {
                    ^
                    convenience 
Untitled 2.swift:4:21: error: 'required' initializer must be declared directly in class 'NSString' (not in an extension)
    public required init(from decoder: Decoder) throws {
           ~~~~~~~~ ^
Untitled 2.swift:4:21: error: initializer requirement 'init(from:)' can only be satisfied by a `required` initializer in the definition of non-final class 'NSString'
    public required init(from decoder: Decoder) throws {
                    ^

in the same way that

import Foundation

extension NSString {
    public required init<T>(_ foo: T) {
        print("NSString.init<\(T.self)>(_:)")
        self.init(string: "Hello!")
    }
}

produces

Untitled 2.swift:4:21: error: designated initializer cannot be declared in an extension of 'NSString'; did you mean this to be a convenience initializer?
    public required init<T>(_ foo: T) {
                    ^
                    convenience 
Untitled 2.swift:4:21: error: 'required' initializer must be declared directly in class 'NSString' (not in an extension)
    public required init<T>(_ foo: T) {
           ~~~~~~~~ ^

The SO question just ommitted the relevant error there.

Comment by Aaron Von Gauss (JIRA)

I personally wouldn't describe this as a beginner issue, I think its more of a gap in the implementation. Logically, for any Type that is marked Decodable or Encodable either directly or indirectly through inheritance the compiler should have the potential to offer a default (codgen) implementation of CodingKeys, init(from🙂 and/or encode(to🙂 appropriately. The CodingKeys if present in the source or generated belong to the Type and should be private to that Type. Having the compiler evaluate and work with each individual Type I would think would produce the expected (desirable) behavior.