Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> Changing how Objective-C initializers are imported sounds like a big and > dangerous task, but factory initializers behave exactly how Objective-C > initializers behave, compared to Swift initializers. Importing them all as > `fatory` init wouldn't change the behavior in any way, only mark

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

I have thought of `static init`, but there are two problems with it: * The `static`-ness of it is purely an implementational detail and is not related to the purpose of these initializers. * The term "static initializer" has another meaning in Objective-C (and other languages) that initializes

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

For value types, my rationale for requiring the “factory” keyword was mostly for unification of expected initializer behavior: you cannot return a value from an initializer, unless it is marked as factory. Already it feels weird that assigning to self is valid in a value type but not in a

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Sun, Jun 11, 2017 at 3:49 PM, Riley Testut wrote: > Some thoughts on updated proposal: > > • I strongly believe factory initializers should follow the progressive > disclosure pattern, and importing all Objective-C initializers as factory > initializers breaks this.

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Some thoughts on updated proposal: • I strongly believe factory initializers should follow the progressive disclosure pattern, and importing all Objective-C initializers as factory initializers breaks this. While there is precedent for this because of the "open" access control, I'd prefer if

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Here's the updated proposal: https://github.com/technogen-gg/swift-evolution/blob/master/proposals/-factory-initializers.md Is there anything else or are we good to go? > On Jun 11, 2017,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

I prefer ‘factory’ myself. Charles > On Jun 11, 2017, at 4:04 AM, Michael Grewal via swift-evolution > wrote: > > Hey how about a new company called > Kernal*saun*$eeders*=ultimatetruecode.ORG > I have the I dream of the kings of live

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Hey how about a new company called Kernal*saun*$eeders*=ultimatetruecode.ORG I have the I dream of the kings of live script support No one can top us Sent from my iPhone On Jun 10, 2017, at 3:12 PM, Riley Testut via swift-evolution wrote: Awesome! Updated my

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Sun, Jun 11, 2017 at 12:43 PM, Gor Gyolchanyan 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Sun, Jun 11, 2017 at 3:56 AM, Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote: > Can you point me towards the changes to the `self.` so I can catch up to > what I might have missed? > I remember it causing trouble, especially with things like this: > > extension MyType:

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Sun, Jun 11, 2017 at 10:34 AM, Gor Gyolchanyan 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 >

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

I may have messed up the generic function example, because you have to specify `A.IntegerLiteralType`, but the idea still stands within protocols and protocol extensions. > On Jun 11, 2017, at 11:56 AM, Gor Gyolchanyan wrote: > > Can you point me towards the changes to

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

My point is: this is the exact problem of making access to local types and members by `Self.` and `self.` optional. It's counter-intuitive. Preferring globals for unqualified access is all good and well, but unless the overarching requirement to qualify local access is in place, it's going to

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Sun, Jun 11, 2017 at 8:49 AM, Gor Gyolchanyan 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Can you recall the reasons why the removal of access modifiers on extensions was rejected? Also, do you think `indirect init` is confusing inside an `indirect enum`? > On Jun 11, 2017, at 4:40 PM, Xiaodi Wu wrote: > > Removal of access modifiers on extensions has been

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Can you point me towards the changes to the `self.` so I can catch up to what I might have missed? I remember it causing trouble, especially with things like this: extension MyType: ExpressibleByIntegerLiteral { public typealias IntegerLiteralType = UInt64 public

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

self. is a different story. It’s absence has become quite popular out in the wild and it’s becoming even more optional in Swift 4. A week or two ago Slava Pestov said on twitter that he has fixed several bugs that made self. even more optional though the whole language. Personally I don’t care

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Hmm I think I can answer my own question myself. To refer to something global you can use ModuleName.globalEntity. But I assume we still have to prefer some global values over local ones for different technical reasons, don’t we? --  Adrian Zubarev Sent with Airmail Am 11. Juni 2017 um

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Cc’ed to Slava Pestov. Well I can’t really, he has only mentioned that change, but I had not searched for a specific commit or PR on Github. I think it’s the correct behavior to prefer global values over local ones if there is a optional conventional shortcut, because how would you be able

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

There was another proposal that got rejected, which was about forcing the usage of `self.` on members. I pretty much *require* it in my code for two reasons: * The understandable requirement of `self.` in closures conflicts with the lack of `self.` in methods, which is confusing. * The ability

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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 could be used directly inside an init: class MyView

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

The difference between a convenience initializer and an indirect initializer is that convenience initializer has to initialize an existing instance, so its options of delegating the responsibility are limited by the guarantees that the initializer requires. On the other hand, an indirect

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

IIRC I had a discussion with Douglas Gregor about the overriding aspect of factory initializers, and the takeaway was that it would just be like convenience initializers. Technically, convenience initializers cannot be overridden, but a subclass *can* implement a convenience method with the

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Looks good, but I have a few thoughts on it: * I think indirect initializers *shoud* be overridable, but only by other indirect initializers. This will allow subclasses of the factory to expand the factory method by adding new possible instances to return. * You did not include the

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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/-factory-initializers.md > On Jun 10,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> > 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 5:32 PM, Gor Gyolchanyan wrote: > Forked swift-evolution, created a draft proposal: > > https://github.com/technogen-gg/swift-evolution/blob/ > master/proposals/-uniform-initialization.md > > This is my first proposal, so I might have missed

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Forked swift-evolution, created a draft proposal: https://github.com/technogen-gg/swift-evolution/blob/master/proposals/-uniform-initialization.md This is my first proposal, so I might

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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 wrote: > You know, come to think of it, I totally agree,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 07:33 Gor Gyolchanyan 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan 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 >

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution > 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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Well I was referring to the title of (1) not to the addition it creates with failable initializers, which I guess is fine by me, but I’d need a more detailed proposal or draft to provide better feedback though. --  Adrian Zubarev Sent with Airmail Am 8. Juni 2017 um 17:51:28, Gor Gyolchanyan

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is a chance for Swift to support init(_ other: Self) { self = other } for classes. Joe Groff replied this is called “factory initializer”. This feature is highly needed for all the iOS developers out there who abuse NIBs and

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

The problem is, it's not clear what assumptions the swift compiler may have on the semantics of initializers. There may be aggressive optimizations going on under the hood with the knowledge that the returned type is the static type that is being initialized. This guaranteed lack of

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Not exactly. #1 is an addition to the language syntax. It's simply a convenient way of expressing failure in a failable initializer the logic of which is already implemented, while extending the syntax in a way that would require zero effort to enable a potential factory initializers. > On Jun

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

To clarify further about DefaultInitializable: An uninitialized variable of a DefaultInitializable type will *only* have its `init()` called if it's accessed before being initialized manually. This will ensure that the variable will never be initialized twice. > On Jun 8, 2017, at 6:20 PM,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Yeah, it's just a small syntactic sugar that doesn't change the current behavior at all, it merely makes initialization syntax more uniform and consistent. Also, something just occurred to me: When we're dealing with convenience initializers, there's the syntax `self.init(...)`, wouldn't it

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 9:19 AM, David Sweeris via swift-evolution > wrote: > > #1 & #3 would violate Swift's rule about having to fully initialize all > properties in inits. > > My initial reaction is to like #2, though, assuming I understand it correctly. Assigning

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Could you please elaborate why #1 and #3 would violate the rule? About #1: Currently, before all members are initialized, attempts to call to `super.init` or escape `self` will be met with a compile-time error. The idea behind `self = nil` is to mark the initializer as `going to fail on

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution > wrote: > > Disclaimer: I do realize that any of the following ideas may have been > discussed before and/or there might be a good reason for their lack of > implementation, so please go easy in me. 

[swift-evolution] [Proposal] Uniform Initialization Syntax

Disclaimer: I do realize that any of the following ideas may have been discussed before and/or there might be a good reason for their lack of implementation, so please go easy in me.  1. Arbitrary `self` Assignments In Intializers The first ideas is to allow `self = nil` inside failable