> On Oct 3, 2017, at 10:18 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Oct 3, 2017, at 10:17 PM, Chris Lattner <clatt...@nondot.org >> <mailto:clatt...@nondot.org>> wrote: >> >>> >>> On Oct 3, 2017, at 10:15 PM, Slava Pestov <spes...@apple.com >>> <mailto:spes...@apple.com>> wrote: >>> >>> >>> >>>> On Oct 3, 2017, at 10:14 PM, Chris Lattner <clatt...@nondot.org >>>> <mailto:clatt...@nondot.org>> wrote: >>>> >>>> On Oct 2, 2017, at 11:11 PM, Slava Pestov <spes...@apple.com >>>> <mailto: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?
My point is that NSObject isn’t a special case. It is simply a very commonly known case right now. While I agree that we can ignore this concern in the short term, in the long term evolution of Swift, the exact same concept will pop up at some point. It is a really really high value optimization for things that are at a low level of the stack. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
