[swift-evolution] Pitch: Restrict Cross-module Struct Initializers
jordan_rose at apple.com
Fri Oct 6 17:26:42 CDT 2017
Oh, sorry, the missing piece of that is 'inlinable': an inlinable memberwise initializer in a fixed-layout struct should have no performance overhead in an optimized build.
> On Oct 6, 2017, at 15:25, Jordan Rose <jordan_rose at apple.com> wrote:
> Good question. Slava and I talked about that and decided that there wasn't much point. '_fixed_layout' still doesn't cover the invariant problem, and memberwise initializers are really common when that's not relevant. We don't think there should ever be a reason to write _fixed_layout in a source package, and we wouldn't want this to become one.
>> On Oct 6, 2017, at 15:23, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> Presumably, @_fixed_layout and its future formalized cousin would restore the current functionality?
>> On Fri, Oct 6, 2017 at 16:32 Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> While working on the non-exhaustive enums proposal I had it pointed out to me that structs actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an extension in another module. We really want people to be able to change the stored properties in their structs between releases without it being a source break—that's half the point of computed properties—and it's also important for a struct author to be able to enforce invariants across the struct's properties. So after talking to a few other Apple Swift folks I put together this proposal:
>> https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md <https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md>
>> This one's way smaller than the enum one, and hopefully fairly uncontroversial. Feedback welcome!
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution