[swift-evolution] [Proposal] Partial initializers

Jordan Rose jordan_rose at apple.com
Thu Jan 21 10:54:16 CST 2016


> On Jan 20, 2016, at 21:10 , Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Jan 20, 2016, at 8:55 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
> 
>> 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.
> 
> I don’t think that’s a huge problem though. When we emit a diagnostic about an uninitialized value or use, we could also emit a series of ‘inlined from here’ notes.

I think it's the other way around: when everything is correct, a new reader will look at the code and say "wait, why are you allowed to pass this inout here?" That applies less to partial initializers, though, which do have some syntax called out. We'd have to check with Chris to be sure, though, since it was a deliberate change at some point in the project's life.

(It's also possible there's a pass ordering problem where we use DI to determine what can be promoted to the stack, or something like that. I'm not too familiar with the mandatory passes.)

> 
>> 
>> We also wouldn't want the other semantics of transparent <https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst>: no debug info,
> 
> That sounds unfortunate. Why is debug info with transparent functions any more of an issue than debug info for stuff inlined by the optimizer passes? I’m assuming we emit debug info for the latter.

No, you've got it backwards. This is a feature of transparent. Nobody wants to step into +.

Now, we could break that feature out into a separate attribute, but then there's nothing "transparent" anymore. It's just "inline very early while we still have source locations to do diagnostics".

Obviously, forced inlining can also hurt code size.


> 
>> and restrictions on what can be mentioned if it's marked public.
>> 
> 
> Arguably, public partial inits only make sense for @_fixed_layout structs anyway :-)

But it affects initializer methods, which are just normal methods otherwise.

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


More information about the swift-evolution mailing list