Don't force inlinable constructors to delegate in non-resilient code #14721
Conversation
This restriction came from wanting to make resilient and non-resilient code follow the same rules whenever possible, but after thinking about it a bit more we realized there was no reason why you /wouldn't/ just mark your structs @_fixed_layout in non-resilient libraries anyway. Since that (currently?) doesn't affect what you can do with the struct across module boundaries, and since the layout of the struct is available anyway in a non-resilient library, there's no real downside, which means it's a meaningless restriction. The same logic doesn't /quite/ apply to classes, since classes are normally much more flexible than structs. (For example, you could add a stored property to a class without recompiling clients, as long as no initializers are inlined.) But it's close enough that we don't want to put in the restriction at this time. All of this is about attributes that haven't been finalized yet anyway (hence the leading underscore), but it's still useful information. rdar://problem/37408668
|
@swift-ci Please test |
|
@jckarter, can you review this since both Slava and Doug are out? You can check out the Radar for a bit more background, too. |
|
So, the correctness condition here is "can all modules that can inline this constructor access the type non-resiliently?". It's not totally clear to me that the new condition actually establishes that; if we're adding a constructor to a type outside its defining module but with non-resilient access to it, is it possible that someone might see our constructor that doesn't have such access? |
|
No, this only applies to constructors defined within the same module. Constructors across modules are still subject to SE-0189, because otherwise adding a new field is a source-breaking change. For constructors defined in the same module, I think that condition is sufficient, yes. |
|
Ah, I see. Yes, in that case I agree. |
This restriction came from wanting to make resilient and non-resilient code follow the same rules whenever possible, but after thinking about it a bit more we realized there was no reason why you wouldn't just mark your structs
@_fixed_layoutin non-resilient libraries anyway. Since that (currently?) doesn't affect what you can do with the struct across module boundaries, and since the layout of the struct is available anyway in a non-resilient library, there's no real downside, which means it's a meaningless restriction.The same logic doesn't quite apply to classes, since classes are normally much more flexible than structs. (For example, you could add a stored property to a class without recompiling clients, as long as no initializers are inlined.) But it's close enough that we don't want to put in the restriction at this time.
All of this is about attributes that haven't been finalized yet anyway (hence the leading underscore), but it's still useful information.
rdar://problem/37408668