> On Oct 3, 2017, at 10:17 PM, Chris Lattner <clatt...@nondot.org> wrote: > >> >> On Oct 3, 2017, at 10:15 PM, Slava Pestov <spes...@apple.com> wrote: >> >> >> >>> 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. > > But everyone knows that NSObject is fixed size, right?
Yeah, but the compiler could handle NSObject as a special case. Are there enough other special cases that it is worth documenting and exposing a fragile attribute on classes to the user? Slava > > -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
