> On Dec 22, 2015, at 9:43 AM, Matthew Johnson <[email protected]> wrote: > > Adding a new member to a struct is itself a breaking change. I don’t see how > memberwise initialization makes this worse.
It may have been a bad example as you handle the case where they wouldn’t be a breaking change by promoting the default initialization to the memberwise init(). > Also, keep in mind that nothing in this proposal is *required*. You can > always decline to use the feature. My point is the same with what’s going on in the “final as default” thread. Features that create public contracts that are hard to guarantee over the lifetime of a project, especially when those contracts weren’t being made explicitly, are hard to maintain over the life of the product. I think it’s important to address what the fragility of the API is for versioning and how that’s being addressed, but that’s just my opinion. > Do you have any suggestions on how to improve the proposal without giving up > on its underlying goal of solving the M x N complexity problem (M members x N > initializers)? No. In my opinion, this is the fragile part of the solution though. I get the desire to reduce that part of the boiler plate, but I don’t know how to solve that part of the problem without a bunch of annotations that end up being more work than just implementing the init() yourself. -David _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
