It’s just hard to tell what that is with several people involved. Any recommendations on how to handle this when writing a proposal?
I don't think you'd know for real until it got to review. This list is high enough traffic that there are probably a lot of people who don't read the drafts, including members of the core team. :-/
Sure. But it might be nice to be able to write a proposal “modulo syntax”. We need placeholder syntax of course, but in many cases it might be best to allow that to be hashed out during review with the core team deciding on the final details if the proposal is accepted. There have been several cases where this seems like an appropriate way to handle things. What do you think?
I like to use the worst syntax I can think of that's still immediately clear: for operators, @precise_ugly_name for attributes, etc. :-)
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.
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.
and restrictions on what can be mentioned if it's marked public.
Arguably, public partial inits only make sense for @_fixed_layout structs anyway :-)
I don’t understand that comment. What is the argument that they only make sense for @_fixed_layout structs? It feels like a generally useful feature to me.
It seems partial initializers leak out what the stored properties of a type are to callers. Resiliently adding stored properties or changing stored properties into computed properties seems like it might cause difficulties for existing code that makes use of partial initializers. It is not clear to me what the guidelines would be for evolving partial initializers.
If this doesn’t make sense to you, take a look at Jordan’s docs/LibraryEvolution.rst — but also keep in mind that outside of system frameworks, all value types are implicitly @_fixed_layout.
Slava
···
On Jan 21, 2016, at 11:44 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Jan 20, 2016, at 11:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Jan 20, 2016, at 8:55 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
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.
If we just go with @_transparent functions for partial initialization, there are no new rules to add regarding ABI resilience. :-)
Ignoring the fact that @_transparent isn’t a user feature, I don’t see how this helps. Mandatory inlining of @_transparent happens after DI runs.
Sorry, I didn’t see that Jordan brought this up down-thread: He’s exactly right. We don’t *want* mandatory inlining to run before DI (it used to, and it was a mess).
Ah, I didn’t know that it was already tried and rejected. I guess @_transparent is the wrong thing to hang this off of, then.
I’m not sold on the notion of partial initializers in the first place, but if we were to go down this path, the approach of nailing down the exact initialization behavior and requirements of the partial initializer - and making it part of its explicitly declared interface - is the right way to go.
Fair enough. I’m also worried about the prospect of adding even more complexity — and syntax — to Swift’s initializer model. My hope is that we can map this to existing language features somehow, or combine this with some other simplification of the initializer model so that the net complexity gain is not too high. But since I don’t have any concrete suggestions at this point, I’ll stay quiet for a while ;-)
Slava
···
On Jan 21, 2016, at 9:16 PM, Chris Lattner <clattner@apple.com> wrote:
On Jan 21, 2016, at 9:13 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 20, 2016, at 8:51 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 20, 2016, at 8:46 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 21, 2016, at 9:20 PM, Slava Pestov <spestov@apple.com> wrote:
I’m not sold on the notion of partial initializers in the first place, but if we were to go down this path, the approach of nailing down the exact initialization behavior and requirements of the partial initializer - and making it part of its explicitly declared interface - is the right way to go.
Fair enough. I’m also worried about the prospect of adding even more complexity — and syntax — to Swift’s initializer model. My hope is that we can map this to existing language features somehow, or combine this with some other simplification of the initializer model so that the net complexity gain is not too high. But since I don’t have any concrete suggestions at this point, I’ll stay quiet for a while ;-)
I feel like "macro system" is probably the right way to approach features
whose purpose is to help developers not write boilerplate.
I know we have a philosophy that warns us to not allow the idea of macro
system to become a crutch that precludes us designing features well. I
think the opposite also applies - if there's something that's a good fit
for a macro system, it probably makes sense to defer it rather than trying
to add it in as language syntax and features that can't pay for themselves
in terms of complexity.
Best,
Austin
···
On Thu, Jan 21, 2016 at 9:48 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
On Jan 21, 2016, at 9:20 PM, Slava Pestov <spestov@apple.com> wrote:
I’m not sold on the notion of partial initializers in the first place, but
if we were to go down this path, the approach of nailing down the exact
initialization behavior and requirements of the partial initializer - and
making it part of its explicitly declared interface - is the right way to
go.
Fair enough. I’m also worried about the prospect of adding even more
complexity — and syntax — to Swift’s initializer model. My hope is that we
can map this to existing language features somehow, or combine this with
some other simplification of the initializer model so that the net
complexity gain is not too high. But since I don’t have any concrete
suggestions at this point, I’ll stay quiet for a while ;-)
I love macro systems but I think most of the pain comes from poor compiler support.
Even if we had some sort of template system like c++ baked into swift for doing this boiler plate I think it would be great
···
Sent from my iPhone
On 22 Jan 2016, at 06:01, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:
I feel like "macro system" is probably the right way to approach features whose purpose is to help developers not write boilerplate.
I know we have a philosophy that warns us to not allow the idea of macro system to become a crutch that precludes us designing features well. I think the opposite also applies - if there's something that's a good fit for a macro system, it probably makes sense to defer it rather than trying to add it in as language syntax and features that can't pay for themselves in terms of complexity.
Best,
Austin
On Thu, Jan 21, 2016 at 9:48 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 21, 2016, at 9:20 PM, Slava Pestov <spestov@apple.com> wrote:
I’m not sold on the notion of partial initializers in the first place, but if we were to go down this path, the approach of nailing down the exact initialization behavior and requirements of the partial initializer - and making it part of its explicitly declared interface - is the right way to go.
Fair enough. I’m also worried about the prospect of adding even more complexity — and syntax — to Swift’s initializer model. My hope is that we can map this to existing language features somehow, or combine this with some other simplification of the initializer model so that the net complexity gain is not too high. But since I don’t have any concrete suggestions at this point, I’ll stay quiet for a while ;-)
for operators, @precise_ugly_name for attributes, etc. :-)