> On Oct 3, 2017, at 10:14 PM, Chris Lattner <clatt...@nondot.org> wrote: > > On Oct 2, 2017, at 11:11 PM, Slava Pestov <spes...@apple.com> 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. Slava _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
