Here's the updated proposal: https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md <https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md>
Is there anything else or are we good to go? > On Jun 11, 2017, at 8:46 PM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Jun 11, 2017 at 12:43 PM, Gor Gyolchanyan <[email protected] > <mailto:[email protected]>> wrote: > I have no better name besides a factory initializer for now. > I have thought about this some more and came to this conclusion about the > keyword: > Let the keyword be universally applied to all factory initializers, to > statically enforce the rules of factory initializers (see below), because the > more I think of it, the more I realize that you'd generally not want to mix > factory and non-factory initializers, due to their vastly differing purposes. > > Having said that, my current understanding of this proposal is as follows: > > * Allow marking initializers inside protocol extensions, class declarations > and class extensions as `factory`. > * In initializers marked as `factory`: > * Change the implicit `self` parameter to mean `the dynamic type of the > enclosing type` (just like it does in static methods). > * Disallow delegating initialization to initializers not marked as > `factory`. > * Require terminating the initializer by either returning a compatible > type (a conforming type for protocols, a derived instance for classes) or > returning `nil` (if the initializer is failable). > * In initializers inside enum declarations, enum extensions, struct > declarations and struct extensions: > * Allow terminating the initializer by returning an instance of the > type being initialized. > > Sounds reasonable to me. > >> On Jun 11, 2017, at 7:38 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sun, Jun 11, 2017 at 10:34 AM, Gor Gyolchanyan <[email protected] >> <mailto:[email protected]>> wrote: >> I just didn't want to use the commonly proposed `factory` word, because it >> implies a specific semantic tied to the factory method pattern. >> I gave it another thought and I'm thinking maybe we can forego the >> annotation and have the compiler deduce it automatically. >> There are only two places where an indirect initializer can exist: >> * Protocol extensions, returning a conforming type. >> * Classes, returning an instance. >> It doesn't make sense to have this on value types, since they do not have >> subtypes of any kind. >> Indirect initializers are very unambiguous in protocol extensions, because >> the only other way of implementing an initializer in a protocol extension is >> via delegating initialization, so the indirect-ness of the initializer can >> be statically determined by whether or not there is a delegating initializer >> involved. >> If the initializer in a protocol extension has a delegating initialization >> on any execution path, then returning an instance is disallowed and vice >> versa. This will ensure strict separation of initializer types for the >> compiler to generate code for. >> If a failable initializer in a protocol extension unconditionally returns >> `nil`, then no initialization takes place anyway, so it doesn't matter, >> which one the compiler chooses. >> In classes this is a bit difficult, because besides delegating initializers, >> they also can initialize the members directly. >> So, in addition to the distinguishing rule for the protocol extensions, >> classes will also check whether any member is assigned to on any execution >> path. >> >> What do you think? >> >> Keywords aren't just for the compiler; they're for the human reader too! If >> you believe the use of your proposed feature in protocol extensions is >> unambiguous to humans as well as compilers, then IMO it makes sense not to >> require another keyword in that place. I haven't thought deeply about >> whether that would be the case. >> >> Clearly, you're saying that this is a more complicated situation with >> classes; I think it makes sense for you to consider requiring a keyword >> there. There is precedent for keywords modifying `init` to be required for >> classes but not for value types (e.g., `convenience`). >> >> Regardless of whether a keyword is required or not, your feature needs a >> name. And here again, I think it is puzzling that you are calling them >> "indirect initializers" when there is already another meaning for "indirect" >> in Swift. Distinct concepts should have distinct names. >> >>> On Jun 11, 2017, at 5:53 PM, Xiaodi Wu <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Sun, Jun 11, 2017 at 8:49 AM, Gor Gyolchanyan <[email protected] >>> <mailto:[email protected]>> wrote: >>> Can you recall the reasons why the removal of access modifiers on >>> extensions was rejected? >>> >>> It was an unassailable reason, really: people found this shorthand useful >>> and wanted to continue to use it--it is the only way to specify that >>> multiple members are public without explicitly labeling each one. The core >>> team agreed it was useful. >>> >>> My takeaway from the whole episode (I was greatly in favor of removing this >>> shorthand, as it's highly inconsistent with all other access modifier >>> rules) is that in general, since the bar for new syntax is so high, if a >>> shorthand made it into the language (and especially if it's kind of an >>> inconsistent shorthand) the general presumption must be that it is highly >>> desired. >>> >>> Also, do you think `indirect init` is confusing inside an `indirect enum`? >>> >>> I do. These are unrelated definitions of "indirect," and I'm puzzled why >>> you'd actively choose to run into issues with the same word meaning two >>> things when you could choose another word. >>> >>>> On Jun 11, 2017, at 4:40 PM, Xiaodi Wu <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Removal of access modifiers on extensions has been proposed, reviewed, and >>>> rejected, so that’s that. >>>> >>>> In general, Swift uses distinct keywords for distinct concepts, unlike >>>> Rust which likes to reuse keywords in clever ways; if you’re finding that >>>> things are getting confusing with one word meaning two things, that >>>> shouldn’t be an invitation to rip out existing syntax but is probably a >>>> good sign you shouldn’t be repurposing that keyword. >>>> >>>> >>>> On Sun, Jun 11, 2017 at 03:28 Adrian Zubarev via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> Yeah, well I messed up my proposal from last year about removing the >>>> access modifier on extensions and wish now I wasn’t that confused back >>>> than and made it right. >>>> >>>> The indirect keyword is literally the same story. The docs only says that >>>> this is only a shortcut. >>>> >>>> „To enable indirection for all the cases of an enumeration, mark the >>>> entire enumeration with the indirect modifier—this is convenient when the >>>> enumeration contains many cases that would each need to be marked with the >>>> indirect modifier.“ >>>> >>>> If you really wish to reuse that keyword here we might need to remove such >>>> shortcuts from the language (indirect enum, access modifier on extensions, >>>> anything else?). >>>> >>>> >>>> >>>> >>>> -- >>>> Adrian Zubarev >>>> Sent with Airmail >>>> >>>> Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan ([email protected] >>>> <mailto:[email protected]>) schrieb: >>>> >>>>> I always wondered, why is `indirect` allowed on the `enum` itself? >>>>> Wouldn't it make more sense to apply it to individual cases that >>>>> recursively refer to the `enum`? >>>>> This question also applies to access modifiers on extensions. So, what is >>>>> it supposed to do? Change the default access modifier from `internal` to >>>>> whatever I specify? That's just confusing, reduces readability and the >>>>> syntactic gain is marginal at best. >>>>> If the `indirect` confusion becomes real, I'd suggest getting rid of >>>>> `indirect enum` and using `indirect case` instead. >>>>> >>>>>> On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> The proposal is looking good to me. :) It will also enable easy support >>>>>> for custom views using XIBs in iOS development without unnecessary view >>>>>> nesting. >>>>>> >>>>>> For instance the function from this example >>>>>> https://stackoverflow.com/a/43123783/4572536 >>>>>> <https://stackoverflow.com/a/43123783/4572536> could be used directly >>>>>> inside an init: >>>>>> >>>>>> class MyView : UIView { >>>>>> >>>>>> indirect init() { >>>>>> return MyView.instantiateFromXib() >>>>>> // Or after SR-0068 >>>>>> return Self.instantiateFromXib() >>>>>> } >>>>>> } >>>>>> There is still one little thing that bothers me, it might be a little >>>>>> bit confusing to have two different meanings of indirect on enums. >>>>>> >>>>>> indirect enum ArithmeticExpression { >>>>>> case number(Int) >>>>>> case addition(ArithmeticExpression, ArithmeticExpression) >>>>>> case multiplication(ArithmeticExpression, ArithmeticExpression) >>>>>> >>>>>> // This might makes no sense, but it would still be possible after >>>>>> // this proposal. >>>>>> indirect init(other: ArithmeticExpression) { >>>>>> return other >>>>>> } >>>>>> >>>>>> // Furthermore if the keyboard is applied to the enum >>>>>> // directly all other `indirect` uses are inferred. >>>>>> // Will this be implicitly `indirect` because of the previous fact? >>>>>> >>>>>> init() { … } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Adrian Zubarev >>>>>> Sent with Airmail >>>>>> >>>>>> Am 11. Juni 2017 um 00:38:56, Riley Testut via swift-evolution >>>>>> ([email protected] <mailto:[email protected]>) schrieb: >>>>>> >>>>>>> Awesome! Updated my proposal to include what I believed to be the >>>>>>> relevant portions of your indirect initializer idea. Let me know if >>>>>>> there’s anything I missed or should change :-) >>>>>>> >>>>>>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md >>>>>>> >>>>>>> <https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md> >>>>>>>> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Hi, Riley! >>>>>>>> >>>>>>>> I think that's a great idea! We can merge the second part of my >>>>>>>> proposal (the `indirect init`) into your one and refine and >>>>>>>> consolidate the prerequisite proposal (about returning from `init` and >>>>>>>> possibly in-place member initializers) and bunch them up into a >>>>>>>> proposal cluster (the way swift coders did). >>>>>>>> Feel free to tear out any chunks from my proposal, while I think about >>>>>>>> a more in-depth rationale about revamping initialization syntax. 🙂 >>>>>>>> >>>>>>>>> On Jun 10, 2017, at 8:36 PM, Riley Testut <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Hi Gor 👋 >>>>>>>>> >>>>>>>>> I’m very much in fan of a unified initialization syntax. I submitted >>>>>>>>> my own proposal for factory initializers a while back, but since it >>>>>>>>> wasn’t a focus of Swift 3 or 4 I haven’t followed up on it recently. >>>>>>>>> In the time since last working on it, I came to my own conclusion >>>>>>>>> that rather than focusing on factory initialization, the overall >>>>>>>>> initialization process should be simplified, which I’m glad to see >>>>>>>>> someone else has realized as well :-) >>>>>>>>> >>>>>>>>> Here’s my proposal for reference: >>>>>>>>> https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e >>>>>>>>> >>>>>>>>> <https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e> >>>>>>>>> Originally I used the “factory” keyword, but I think your “indirect” >>>>>>>>> keyword may be a better fit (since it has precedent in the language >>>>>>>>> and is not limited to “just” being about factory initialization). To >>>>>>>>> divide your proposal up into smaller pieces for review, maybe we >>>>>>>>> could update my proposal to use your indirect keyword, and then start >>>>>>>>> a separate topic/proposal for the remaining aspects of your proposal? >>>>>>>>> I agree that splitting it into smaller chunks may be better for the >>>>>>>>> process. >>>>>>>>> >>>>>>>>> Let me know what you think! >>>>>>>>> >>>>>>>>> Riley >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution >>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a very interesting read. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks you! I tried to make it as clear and detailed as possible. 🙂 >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We did not discuss the 'indirect' idea at all on this list. Did you >>>>>>>>>>> come up with it just now? In any case, my suggestion as to moving >>>>>>>>>>> forward would be this: >>>>>>>>>>> >>>>>>>>>> I was writing the proposal and was just about to write `factory >>>>>>>>>> init`, when it occurred to me: enums already have a keyword that >>>>>>>>>> does something very similar. It seemed to me that an initializer >>>>>>>>>> that doesn't initialize the instance in-place, but returns a >>>>>>>>>> completely separate instance from somewhere else, is kinda >>>>>>>>>> "indirectly" initializing the instance. Plus, the already >>>>>>>>>> established keyword and its semantic would reduce the learning curve >>>>>>>>>> for this new feature and separate it from a single specific use case >>>>>>>>>> (the "factory method" pattern). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Do you feel that both halves of your draft (expanding `return` in >>>>>>>>>>> initializers, and `indirect` initializers) should absolutely be one >>>>>>>>>>> proposal, or can they be separated? >>>>>>>>>>> >>>>>>>>>> I think the `return` can be easily implemented first, while opening >>>>>>>>>> up an opportunity to later implement `indirect init`. The reason why >>>>>>>>>> I unified them was that the `return` idea on its own has very >>>>>>>>>> limited merit and could the thought of as a low-priority cosmetic >>>>>>>>>> enhancement. I wouldn't want it to be viewed that way because the >>>>>>>>>> primary purpose of that idea is to enable `indirect init` (which >>>>>>>>>> Cocoa and Cocoa Touch developers would be very happy about). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> a) If they can be separated because each half has individual merit, >>>>>>>>>>> then these ideas may be more likely to succeed as separate >>>>>>>>>>> proposals, as each can be critiqued fully and judged independently >>>>>>>>>>> as digestible units. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Very good point. The challenge is to correctly separate them, >>>>>>>>>> without losing context in their respective proposals and without >>>>>>>>>> bleeding the proposals into each other. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> b) If you intend to tackle all your ideas all at once, that's going >>>>>>>>>>> to be a much bigger change--in terms of review effort, likely >>>>>>>>>>> bikeshedding, and implementation effort. It'll probably be best to >>>>>>>>>>> solicit initial feedback on this list first about `indirect` >>>>>>>>>>> initializers, even if just to familiarize the community with the >>>>>>>>>>> idea, before launching into a pitch of the whole proposal. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'd never send a pull request to swift-evolution without thoroughly >>>>>>>>>> discussing it here. I just though, if I'm going to write a whole >>>>>>>>>> proposal with examples and motivation, it would be easier to >>>>>>>>>> demonstrate it and discuss in with the community If I just went >>>>>>>>>> ahead and wrote the whole thing and sent the link. This way it would >>>>>>>>>> be clearer to the reader and the discussed changes would be >>>>>>>>>> accurately reflected by the commits I'd make to my proposal. >>>>>>>>>> >>>>>>>>>> Original Message >>>>>>>>>> >>>>>>>>>>> On Jun 10, 2017, at 2:38 AM, Daryle Walker via swift-evolution >>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 9, 2017 at 5:32 PM, Gor Gyolchanyan >>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>> Forked swift-evolution, created a draft proposal: >>>>>>>>>>> >>>>>>>>>>> https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-uniform-initialization.md >>>>>>>>>>> >>>>>>>>>>> <https://github.com/technogen-gg/swift-evolution/blob/master/proposals/NNNN-uniform-initialization.md> >>>>>>>>>>> >>>>>>>>>>> This is my first proposal, so I might have missed something or >>>>>>>>>>> composed it wrong, so please feel free to comment, fork and send >>>>>>>>>>> pull requests. 🙂 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a very interesting read. We did not discuss the 'indirect' >>>>>>>>>>> idea at all on this list. Did you come up with it just now? In any >>>>>>>>>>> case, my suggestion as to moving forward would be this: >>>>>>>>>>> >>>>>>>>>>> - Do you feel that both halves of your draft (expanding `return` in >>>>>>>>>>> initializers, and `indirect` initializers) should absolutely be one >>>>>>>>>>> proposal, or can they be separated? >>>>>>>>>>> >>>>>>>>>>> a) If they can be separated because each half has individual merit, >>>>>>>>>>> then these ideas may be more likely to succeed as separate >>>>>>>>>>> proposals, as each can be critiqued fully and judged independently >>>>>>>>>>> as digestible units. >>>>>>>>>>> >>>>>>>>>>> b) If you intend to tackle all your ideas all at once, that's going >>>>>>>>>>> to be a much bigger change--in terms of review effort, likely >>>>>>>>>>> bikeshedding, and implementation effort. It'll probably be best to >>>>>>>>>>> solicit initial feedback on this list first about `indirect` >>>>>>>>>>> initializers, even if just to familiarize the community with the >>>>>>>>>>> idea, before launching into a pitch of the whole proposal. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jun 9, 2017, at 3:24 PM, Xiaodi Wu <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Cool. I have reservations about idea #3, but we can tackle that >>>>>>>>>>>> another day. (Real life things beckon.) But suffice it to say that >>>>>>>>>>>> I now really, really like your idea #2. >>>>>>>>>>>> On Fri, Jun 9, 2017 at 08:06 Gor Gyolchanyan <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>> You know, come to think of it, I totally agree, and here's why: >>>>>>>>>>>> A normal initializer (if #2 is accepted) would *conceptually* have >>>>>>>>>>>> the signature: >>>>>>>>>>>> >>>>>>>>>>>> mutating func `init`(...) -> Self >>>>>>>>>>>> >>>>>>>>>>>> Which would mean that both `self` and the returned result are >>>>>>>>>>>> non-optional. >>>>>>>>>>>> A failable initializer could then have the signature: >>>>>>>>>>>> >>>>>>>>>>>> mutating func `init`() -> Self? >>>>>>>>>>>> >>>>>>>>>>>> Which would make the returned result optional, but leave `self` >>>>>>>>>>>> non-optional. >>>>>>>>>>>> This would make `return nil` less out-of-place, like you said, >>>>>>>>>>>> while still leaving `self` as a set-exactly-once `inout Self`. >>>>>>>>>>>> A factory initializer would then have the signature: >>>>>>>>>>>> >>>>>>>>>>>> static func `init`(...) -> Self >>>>>>>>>>>> >>>>>>>>>>>> or in case of a failable factory initializer: >>>>>>>>>>>> >>>>>>>>>>>> static func `init`(...) -> Self? >>>>>>>>>>>> >>>>>>>>>>>> Which would still make sense with the now legal `return ...` >>>>>>>>>>>> syntax, while adding the restriction of not having any `self` at >>>>>>>>>>>> all. >>>>>>>>>>>> So, annotating the initializer with the keyword `factory` would >>>>>>>>>>>> cause it to change the signature as well as remove any compiler >>>>>>>>>>>> assumptions about the dynamic type of the returned instance. >>>>>>>>>>>> >>>>>>>>>>>> In addition, idea #3 would be available for more deterministic >>>>>>>>>>>> in-place initialization. >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 9, 2017, at 2:47 PM, Xiaodi Wu <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Jun 9, 2017 at 07:33 Gor Gyolchanyan >>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>> So far, we've discussed two ways of interpreting `self = nil`, >>>>>>>>>>>>> both of which have a sensible solution, in my opinion: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. It's a special rule like you said, which can be seen as >>>>>>>>>>>>> counter-intuitive, but recall that `return nil` is just as much >>>>>>>>>>>>> of a special rule and is also largely counter-intuitive. >>>>>>>>>>>>> >>>>>>>>>>>>> `return nil` is “special,” but it doesn’t conflict with any other >>>>>>>>>>>>> syntax because the initializer notionally has no return value. >>>>>>>>>>>>> Personally, I have always disliked `return nil` in failable >>>>>>>>>>>>> initializers for that reason, but I couldn’t come up with a >>>>>>>>>>>>> better alternative. >>>>>>>>>>>>> >>>>>>>>>>>>> Your proposed idea to allow returning any value is interesting >>>>>>>>>>>>> because, in the case of a failable initializer, `return nil` >>>>>>>>>>>>> continues to have the same meaning if we consider the return >>>>>>>>>>>>> value of the initializer to be of type `Self?`. For that reason, >>>>>>>>>>>>> I think your idea #2 is quite clever, and it would go a long way >>>>>>>>>>>>> in making `return nil` a lot less odd. It also increases the >>>>>>>>>>>>> expressivity of initializers because it allows one to set the >>>>>>>>>>>>> value of self and also return in one statement, clearly >>>>>>>>>>>>> demonstrating the intention that no other code in the initializer >>>>>>>>>>>>> should be run before returning. >>>>>>>>>>>>> >>>>>>>>>>>>> For all of those reasons, I think idea #2 is a winning idea. >>>>>>>>>>>>> >>>>>>>>>>>>> The benefit of `self = nil` is that it's much more in line with >>>>>>>>>>>>> initialization semantics, it provides more uniform syntax and >>>>>>>>>>>>> it's a bit less restrictive. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. It's an `inout Self!`, like Greg said, which can be seen as >>>>>>>>>>>>> more cumbersome. Implicitly unwrapped optionals are a bit >>>>>>>>>>>>> difficult, but this "variation" of it is much more restrictive >>>>>>>>>>>>> then the normal ones, because unlike normal implicitly unwrapped >>>>>>>>>>>>> optionals, this one cannot be accessed after being assigned nil >>>>>>>>>>>>> (and it also cannot be indirectly assigned `nil`, because >>>>>>>>>>>>> escaping `self` is not allowed before full initialization), so >>>>>>>>>>>>> there is only one possible place it can be set to nil and that's >>>>>>>>>>>>> directly in the initializer. This means that `self` can be safely >>>>>>>>>>>>> treated as `inout Self` before being set to nil (and after being >>>>>>>>>>>>> set to nil, it doesn't matter any more because you aren't allowed >>>>>>>>>>>>> to access it, due to not being fully initialized). >>>>>>>>>>>>> >>>>>>>>>>>>> I have to say, I don’t like either of these explanations at all. >>>>>>>>>>>>> I think having a “special” IUO is a difficult sell; it is just >>>>>>>>>>>>> conceptually too complicated, and I don’t agree that it gains you >>>>>>>>>>>>> much. >>>>>>>>>>>>> >>>>>>>>>>>>> By your own admission, `self = nil` is wonky, and making the >>>>>>>>>>>>> language wonkier because it currently has a parallel wonky >>>>>>>>>>>>> feature in `return nil` seems like the wrong way to go. In >>>>>>>>>>>>> addition, there’s nothing gained here that cannot be done with a >>>>>>>>>>>>> defer statement; of course, defer statements might not be very >>>>>>>>>>>>> elegant, but it would certainly be less wonky than inventing a >>>>>>>>>>>>> new variation on an IUO to allow assignment of nil to self... For >>>>>>>>>>>>> those reasons, I conclude that I’m not excited about your idea #1. >>>>>>>>>>>>> >>>>>>>>>>>>> Overall, I'd go with #2 because it involves much less confusing >>>>>>>>>>>>> magic and the restrictions of `self as inout Self!` are imposed >>>>>>>>>>>>> by already existing and well-understood initialization logic, so >>>>>>>>>>>>> the provided guarantees don't really come at the cost of much >>>>>>>>>>>>> clarity. >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jun 9, 2017, at 2:23 PM, Xiaodi Wu <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> I think a good approach would be to have `self = nil` only mean >>>>>>>>>>>>>> `the initializer is going to fail` because if your type is >>>>>>>>>>>>>> ExpressibleByNilLiteral, it means that the `nil` of your type >>>>>>>>>>>>>> already carries the same meaning as if your type was not >>>>>>>>>>>>>> ExpressibleByNilLiteral and was an optional instead, so having a >>>>>>>>>>>>>> failable initializer doesn't really make sense in that case >>>>>>>>>>>>>> (since you could've initialized `self` to its own `nil` in case >>>>>>>>>>>>>> of failure). Still, some valid use cases may exist, so the >>>>>>>>>>>>>> natural (and quite intuitive) way to circumvent this would be to >>>>>>>>>>>>>> call `self.init(nilLiteral: ())` directly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So you would create a special rule that `self = nil` means a >>>>>>>>>>>>>> different thing in an initializer than it does in a function? >>>>>>>>>>>>>> Essentially, then, you’re creating your own variation on an >>>>>>>>>>>>>> implicitly unwrapped optional, where `self` is of type `inout >>>>>>>>>>>>>> Self?` for assignment in initializers only but not for any other >>>>>>>>>>>>>> purpose. Implicitly unwrapped optionals are hard to reason >>>>>>>>>>>>>> about, and having a variation on it would be even harder to >>>>>>>>>>>>>> understand. I don’t think this is a workable design. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It might be possible to have `self` be of type `inout Self?`; >>>>>>>>>>>>>> however, I do think Greg is right that it would create more >>>>>>>>>>>>>> boilerplate than the current situation. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jun 9, 2017, at 2:07 PM, Xiaodi Wu <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> The type of `self` could remain `inout Self` inside the >>>>>>>>>>>>>>> failable initializer. The ability to assign nil would be a >>>>>>>>>>>>>>> compiler magic (much like `return nil` is compiler magic) that >>>>>>>>>>>>>>> is meant to introduce uniformity to the initialization logic. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The idea is to define all different ways initialization can >>>>>>>>>>>>>>> take place and expand them to be used uniformly on both `self` >>>>>>>>>>>>>>> and all its members, as well as remove the ways that do not >>>>>>>>>>>>>>> make sense for their purpose. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently, there are 3 ways of initializing self as a whole: >>>>>>>>>>>>>>> 1. delegating initializer >>>>>>>>>>>>>>> 2. assigning to self >>>>>>>>>>>>>>> 3. returning nil >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #1: The delegating initializer is pretty much perfect at this >>>>>>>>>>>>>>> point, in my opinion, so no changes there. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #2: The only exception in assigning to self is the `nil` inside >>>>>>>>>>>>>>> failable initializers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #3: The only thing that can be returned from an initializer is >>>>>>>>>>>>>>> `nil`, which is compiler magic, so we can thing of it as a >>>>>>>>>>>>>>> misnomer (because we aren't really **returning** anything). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If, for a second, we forget about potential factory >>>>>>>>>>>>>>> initializers, returning anything from an initializer doesn't >>>>>>>>>>>>>>> make much sense, because an initializer is conceptually meant >>>>>>>>>>>>>>> to bring an existing object in memory to a type-specific valid >>>>>>>>>>>>>>> state. This semantic was very explicitly in Objective-C with >>>>>>>>>>>>>>> `[[MyType alloc] init]`. Especially since even syntactically, >>>>>>>>>>>>>>> the initializer does not specify any return type, the idea of >>>>>>>>>>>>>>> returning from an initializer is counter-intuitive both >>>>>>>>>>>>>>> syntactically and semantically. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The actual *behavior* of `return nil` is very sensible, so the >>>>>>>>>>>>>>> behavior, I imagine `self = nil`, would largely mean the same >>>>>>>>>>>>>>> (except not needed to return immediately and allowing >>>>>>>>>>>>>>> non-self-accessing code to be executed before return). Being >>>>>>>>>>>>>>> able to assign `nil` to a non-optional (ExpressibleByNilLiteral >>>>>>>>>>>>>>> doesn't count) may feel a bit wonky, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What happens when Self is ExpressibleByNilLiteral and you want >>>>>>>>>>>>>>> to initialize self to nil? That is what `self = nil` means if >>>>>>>>>>>>>>> `self` is of type `inout Self`. If `self` is of type `inout >>>>>>>>>>>>>>> Self` and Self is not ExpressibleByNilLiteral, then it must be >>>>>>>>>>>>>>> an error to assign nil to self. Anything else does not make >>>>>>>>>>>>>>> sense, unless `self` is of type `inout Self?`. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> but not as wonky as returning nil from something that is meant >>>>>>>>>>>>>>> to initialize an object in-place and doesn't look like it >>>>>>>>>>>>>>> should return anything. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # Factory Initializers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In case of factory initializers, the much discussed `factory >>>>>>>>>>>>>>> init` syntax could completely flip this logic, but making the >>>>>>>>>>>>>>> initializer essentially a static function that returns an >>>>>>>>>>>>>>> object. In this case the initializer could be made to specify >>>>>>>>>>>>>>> the return type (that is the supertype of all possible >>>>>>>>>>>>>>> factory-created objects) and assigning to self would be >>>>>>>>>>>>>>> forbidden because there is not self yet: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> extension MyProtocol { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public factory init(weCool: Bool) -> MyProtocol { >>>>>>>>>>>>>>> self = MyImpl() // error: cannot assign to `self` in a factory >>>>>>>>>>>>>>> initializer >>>>>>>>>>>>>>> self.init(...) // error: cannot make a delegating initializer >>>>>>>>>>>>>>> call in a factory initializer >>>>>>>>>>>>>>> if weCool { >>>>>>>>>>>>>>> return MyCoolImpl() >>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>> return MyUncoolImpl() >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # In-place Member Initializers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In addition, member initialization currently is only possible >>>>>>>>>>>>>>> with #2 (as in `self.member = value`), which could be extended >>>>>>>>>>>>>>> in a non-factory initializer to be initializable in-place like >>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> self.member.init(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This would compliment the delegating initialization syntax, >>>>>>>>>>>>>>> while giving a more reliable performance guarantee that this >>>>>>>>>>>>>>> member will not be copy-initialized. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 9, 2017, at 1:32 PM, Xiaodi Wu <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If `self` is not of type `inout Self?`, then what is the type >>>>>>>>>>>>>>>> of `self` such that you may assign it a value of `nil`? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It certainly cannot be of type `inout Self`, unless `Self` >>>>>>>>>>>>>>>> conforms to `ExpressibleByNilLiteral`, in which case you are >>>>>>>>>>>>>>>> able to assign `self = nil` an unlimited number of times–but >>>>>>>>>>>>>>>> that has a totally different meaning. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could `self` be of type `inout Self!`? Now that implicitly >>>>>>>>>>>>>>>> unwrapped optionals are no longer their own type, I’m not sure >>>>>>>>>>>>>>>> that’s possible. But even if it were, that seems unintuitive >>>>>>>>>>>>>>>> and potentially error-prone. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So I think Greg is quite right that, to enable this feature, >>>>>>>>>>>>>>>> `self` would have to be of type `inout Self?`–which is >>>>>>>>>>>>>>>> intriguing but potentially more boilerplatey than the status >>>>>>>>>>>>>>>> quo. >>>>>>>>>>>>>>>> On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via >>>>>>>>>>>>>>>> swift-evolution <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> Good point, but not necessarily. >>>>>>>>>>>>>>>> Since you cannot access `self` before it being fully >>>>>>>>>>>>>>>> initialized and since `self` can only be initialized once, >>>>>>>>>>>>>>>> this would mean that after `self = nil`, you won't be allowed >>>>>>>>>>>>>>>> to access `self` in your initializer at all.You'll be able to >>>>>>>>>>>>>>>> do any potential, cleanup though. >>>>>>>>>>>>>>>> Also, since there can be only one `self = nil`, there's no >>>>>>>>>>>>>>>> reason to treat `self` as `inout Self?`, because the only >>>>>>>>>>>>>>>> place it can be `nil` is the place it cannot be accessed any >>>>>>>>>>>>>>>> more. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Jun 9, 2017, at 7:45 AM, Greg Parker <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via >>>>>>>>>>>>>>>>>> swift-evolution <[email protected] >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. Arbitrary `self` Assignments In Intializers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The first ideas is to allow `self = nil` inside failable >>>>>>>>>>>>>>>>>> initializers (essentially making `self` look like `inout >>>>>>>>>>>>>>>>>> Self?` instead of `inout Self` with magical `return nil`), >>>>>>>>>>>>>>>>>> so that all initializers uniformly can be written in `self = >>>>>>>>>>>>>>>>>> ...` form for clarity and convenience purposes. This should, >>>>>>>>>>>>>>>>>> theoretically, be nothing but a `defer { return nil }` type >>>>>>>>>>>>>>>>>> of rewrite, so I don't see any major difficulties >>>>>>>>>>>>>>>>>> implementing this. This is especially useful for >>>>>>>>>>>>>>>>>> failable-initializing enums where the main switch simply >>>>>>>>>>>>>>>>>> assigns to self in all cases and the rest of the initializer >>>>>>>>>>>>>>>>>> does some post-processing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't see how to avoid source incompatibility and >>>>>>>>>>>>>>>>> uglification of failable initializer implementations here. >>>>>>>>>>>>>>>>> Allowing `self = nil` inside a failable initializer would >>>>>>>>>>>>>>>>> require `self` to be an optional. That in turn would require >>>>>>>>>>>>>>>>> every use of `self` in the initializer to be nil-checked or >>>>>>>>>>>>>>>>> forced. I don't think that loss everywhere outweighs the gain >>>>>>>>>>>>>>>>> of `self = nil` in some places. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Greg Parker [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> Runtime Wrangler >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> swift-evolution mailing list >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
