> On Oct 3, 2017, at 10:15 PM, Slava Pestov <[email protected]> wrote: > > > >> On Oct 3, 2017, at 10:14 PM, Chris Lattner <[email protected]> wrote: >> >> On Oct 2, 2017, at 11:11 PM, Slava Pestov <[email protected]> wrote: >>>> In any case, even if you’re opposed to these approaches, I’d love for the >>>> “alternatives considered” section to indicate what the objection is. I am >>>> really very concerned that you’re causing a keyword/attribute explosion >>>> and conceptual complexity by adding too many small things to individual >>>> parts of the language. We would ideally have a simple and holistic >>>> solution to resilience. >>> >>> I agree with that keyword/attribute explosion is a concern. We also plan on >>> submitting a proposal to add a @fixedContents attribute for structs >>> (currently implemented as @_fixed_layout) which enables more efficient >>> access patterns in resilient code, for example direct access of stored >>> properties, at the cost of preventing new stored properties from being >>> added in a binary-compatible manner. So we would have ‘nonexhaustive’ >>> enums, @fixedContents structs, and @inlinable >>> functions/properties/initializers. >> >> Yes, and then we’ll need something else for classes as well (*head >> explodes*). > > FWIW, I was hoping we wouldn’t need to expose any such attribute for classes > (or protocols) at all, because classes are already “slow” and anything we do > to make them resilient doesn’t make things much “slower”. But that could > change, of course.
But everyone knows that NSObject is fixed size, right? -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
