[swift-evolution] [Proposal] Partial initializers

[Jordan Rose]

> On Jan 20, 2016, at 20:46 , Slava Pestov <spestov at apple.com> wrote:
> 
>> 
>> On Jan 20, 2016, at 6:48 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> 3. Partial initializers and initialization methods may include an access control modifier specifying their visibility.
>> 
>> I'm a little concerned about exposing these things publicly: there's no point if the struct or class has non-public fields (because new non-delegating initializers can't initialize the non-public fields), and by default every struct and class is allowed to add non-public fields in new versions of a library. (See the LibraryEvolution.rst doc for more info.) I can kind of see making these private vs. internal, but that has other issues (see below).
>> 
>> Even in the case where all fields are public and the struct promises not to change any fields, you'd also have to promise that the partial initializer never changes which properties it's initializing; that's now part of the binary interface of the file. That's unusual for something that behaves like a function; usually the body is not part of the ABI.
>> 
>> I'd much rather just ban 'public' and never have partial inits be part of a library's public interface. Public initializer methods would be presented as plain methods, with no hint of their initializer origins.
>> 
>> 
>>> 9. The compiler keeps track of the properties initialized by a partial initializer or initialization method and uses that knowledge when enforcing initialization rules in phase one in the calling initializer.
>> 
>> If a struct partial initializer is defined in another file, this would require reading the body of the initializer to determine what variables it initializes. We currently don't type-check any bodies outside of the primary source file when doing a normal, multi-process compilation.
>> 
>> You're missing a DI condition here in the sub-bullets, which is that the partial initializer must initialize its subset of stored properties on all paths.
> 
> I believe you can already factor out common code in initializers by defining @_transparent functions. Would it be more worthwhile to improve @_transparent by fixing the known limitations instead?

IIRC mandatory inlining runs after DI. I think Chris didn't want cases where the DI looked wrong but was correct because the called function happened to be inlined—there's no indication at the call site of this.

We also wouldn't want the other semantics of transparent <https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst>: no debug info, and restrictions on what can be mentioned if it's marked public.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/a2ea92c2/attachment.html>