[SR-11454] Adding a designated initializer can be source-breaking

[belkadan]

Previous ID	SR-11454
Radar	None
Original Reporter	@belkadan
Type	Bug

Additional Detail from JIRA

Votes	0
Component/s	Source Tooling
Labels	Bug
Assignee	@nkcsgexi
Priority	Medium

md5: 247a187251c5dc57d0a86c0dd1cd1cae

Issue Description:

Adding a designated initializer to an open class is a source-breaking change, but adding one to a public class can be source-breaking as well if there are subclasses. Consider the following:

// Library.swift
public /* not open */ class Base {
  public init() {}
  public convenience init(foo: Int) {
    self.init()
    print(foo)
  }
}

public class Sub: Base {
  public override init() {}
}

Right now clients are allowed to say Sub(foo: 42). But if a new designated initializer is added to Base (whether public or not), and Sub doesn't override it, then the convenience initializer won't be inherited anymore.

[belkadan]

@harlanhaskins's work in #26060 will make this easier to check for, because it becomes "the addition of this hidden attribute is source-breaking".

[belkadan]

cc @nkcsgexi

[belkadan]

I guess this is kind of runtime-breaking too, since even though a not-recompiled client program will still run the convenience initializer it calls may no longer work with the subclass.