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

[Riley Testut via swift-evolution]

> 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 the 
> initializer as `factory`. However, it does look like Objective-C initializers 
> will have to be a special case, in order for non-factory initializers in 
> Swift to be able to override them.

IIRC, there is already special logic for handling Objective-C initializers from 
Swift; they are effectively implemented as if they were factory initializers. I 
still don’t think we need to explicitly mark them as factory though, as that 
would certainly be confusing to newcomers (and would mess with the 
convenience/required initializer chain).

> We could just drop factory initializers in classes for now and start by only 
> adding them to protocols (which is incomparably easier) and see where this 
> goes first.

I believe factory initializers are most powerful with classes, and since this 
would need to be solved anyway, I think we should move forward with it for all 
types + protocol extensions


> On Jun 12, 2017, at 12:43 AM, Gor Gyolchanyan  wrote:
> 
> 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 the type itself once at the start of the process.
> 
> 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 the 
> initializer as `factory`. However, it does look like Objective-C initializers 
> will have to be a special case, in order for non-factory initializers in 
> Swift to be able to override them.
> 
> *OR*
> 
> The way initializers worked in Objective-C is the opposite of how they work 
> in Swift: `self = [super init]; self.member = value;` (not counting the NULL 
> checks). This allowed overriding them and delegating to them even though 
> they're essentially factory methods. The problem with this was that with 
> Objective-C's poor type safety, it was easy to forget to initialize the 
> members, but with Swift, there's a strong type system for that. What we could 
> do is to make Objective-C's factory initializers create the dynamic type 
> using NSObject's `init()` and have the subclass's factory initializer 
> initialize all its members *after" the  instance is created.
> 
> *OR*
> 
> We could just drop factory initializers in classes for now and start by only 
> adding them to protocols (which is incomparably easier) and see where this 
> goes first.
> 
>> On Jun 12, 2017, at 12:30 AM, Xiaodi Wu > > wrote:
>> 
>> 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. While there is precedent for this because of the 
>> "open" access control, I'd prefer if maybe we compromised and any @objc 
>> initializer is assumed to have the same performance characteristics as a 
>> factory initializer, without having to prepend the factory keyword.
>> 
>> I'm not expert enough on Obj-C interop issues to make insightful comments on 
>> this, but my naive impression here is that changing how _all_ Obj-C 
>> initializers are imported by default seems...risky? Perhaps a summary of how 
>> the compiler currently handles the issue is in order for this proposal, so 
>> as to enable readers to evaluate this change.
>>  
>> • While I did initially propose the factory keyword, I'm still not entirely 
>> sure "factory" is the right choice. Though if the consensus that is the 
>> right keyword, then I'll happily accept that.
>> • Having "self" refer to the dynamic type of the returned instance 
>> seems...weird. While technically correct for a static method, I'd expect 
>> self to be an instance and Self to be the dynamic type just like any other 
>> initializer.
>> 
>> Agree: `self` referring to a type is unprecedented when it's not a static 
>> method--this feels weird. If this is essential for the whole design, have 
>> you considered maybe just calling it `static init`? (This raises a 
>> potentially interesting thought about whether it'd make sense to also have a 
>> `class init`...)
>> 
>> • Factory initializers should be used for any initializer that returns a 
>> value. 

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

[Gor Gyolchanyan via swift-evolution]

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 the type itself once at the start of the process.

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 the 
initializer as `factory`. However, it does look like Objective-C initializers 
will have to be a special case, in order for non-factory initializers in Swift 
to be able to override them.

*OR*

The way initializers worked in Objective-C is the opposite of how they work in 
Swift: `self = [super init]; self.member = value;` (not counting the NULL 
checks). This allowed overriding them and delegating to them even though 
they're essentially factory methods. The problem with this was that with 
Objective-C's poor type safety, it was easy to forget to initialize the 
members, but with Swift, there's a strong type system for that. What we could 
do is to make Objective-C's factory initializers create the dynamic type using 
NSObject's `init()` and have the subclass's factory initializer initialize all 
its members *after" the  instance is created.

*OR*

We could just drop factory initializers in classes for now and start by only 
adding them to protocols (which is incomparably easier) and see where this goes 
first.

> On Jun 12, 2017, at 12:30 AM, Xiaodi Wu  wrote:
> 
> 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. While there is precedent for this because of the 
> "open" access control, I'd prefer if maybe we compromised and any @objc 
> initializer is assumed to have the same performance characteristics as a 
> factory initializer, without having to prepend the factory keyword.
> 
> I'm not expert enough on Obj-C interop issues to make insightful comments on 
> this, but my naive impression here is that changing how _all_ Obj-C 
> initializers are imported by default seems...risky? Perhaps a summary of how 
> the compiler currently handles the issue is in order for this proposal, so as 
> to enable readers to evaluate this change.
>  
> • While I did initially propose the factory keyword, I'm still not entirely 
> sure "factory" is the right choice. Though if the consensus that is the right 
> keyword, then I'll happily accept that.
> • Having "self" refer to the dynamic type of the returned instance 
> seems...weird. While technically correct for a static method, I'd expect self 
> to be an instance and Self to be the dynamic type just like any other 
> initializer.
> 
> Agree: `self` referring to a type is unprecedented when it's not a static 
> method--this feels weird. If this is essential for the whole design, have you 
> considered maybe just calling it `static init`? (This raises a potentially 
> interesting thought about whether it'd make sense to also have a `class 
> init`...)
> 
> • Factory initializers should be used for any initializer that returns a 
> value. Furthermore, I don't think we should limit factory initializers to 
> just protocol extensions and classes. Sure it doesn't make sense for value 
> types, but I don't think we should forbid that (and that way if you want to 
> return a value instead of a assign to self, you'd just use factory intializer)
> • I don't think there should be any delegating to other factory initializers. 
> Nothing would stop you from returning a value initialized via another factory 
> method, however.
> 
> Hmm. That sounds workable and simpler, definitely.
> 
> Sorry if sounds a little rambled, don't have access to a computer for the 
> rest of the day so typing this all up on my phone! 
> 
> On Jun 11, 2017, at 1:39 PM, Gor Gyolchanyan via swift-evolution 
> > wrote:
> 
>> 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, at 8:46 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Sun, Jun 11, 2017 at 12:43 PM, Gor Gyolchanyan >> > wrote:
>>> I have no better name besides a factory initializer for now.
>>> I 

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

[Riley Testut via swift-evolution]

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 reference type, so 
I didn’t want to introduce any more inconsistencies.

While factory initializers are essentially static methods under the hood, I 
don’t think that aspect should leak through to the implementation. IMO, factory 
initializers should be thought of as any other initializer, except for instead 
of assigning to self, you return a value. You are right that the implementation 
to remove access to self may be more effort than it’s worth though (since I 
expect most people won’t use self anyway in factory initializers), and I’d love 
to hear from any Core Team members/contributors about this.

Don’t know if this was discussed in this thread, but what about instead of 
returning values, we simply made factory initializers able to assign to self? 
IIRC Joe Groff said that functionality is already there in the language (and is 
used for Objc initializers), but just isn’t enabled. That could solve the “what 
is self?” debate and be more uniform with current initializers.

> On Jun 11, 2017, at 4:16 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> * I agree, that delegating initialization doesn't make sense at all, one can 
> simply create an instance as usual.
> * Factory initializers are not forbidden for value types, they're simply not 
> required to be annotated as such, due to the fact that value types don't have 
> dynamic types and can be simply `memcpy`-ed as part of initialization.
> * I always thought that `self` referring to the type inside static methods 
> was weird and confusing and error-prone, but as factory initializers are 
> essentially static methods, removing them for the factory initializers alone 
> would be extra work. I'd say, this deserves a proposal of its own.
> * I don't like the `factory` keyword either, because of its semantics, but I 
> honestly can't think of anything better at the moment. If anyone has any 
> suggestions, I'm all ears.
> * I do agree that changing the Objective-C import logic is a tall order, but 
> if it's not done correctly, given the new syntax and semantics, it could 
> introduce even more confusion and inconsistent behavior than it does now. The 
> new attribute __attribute__((swift_factory_init(false))) can be applies to 
> initializers to suppress this, which could be done for the vast majority of 
> the types (except things like NSNull and NSProxy). I'm starting to think that 
> @objc initializers would have to have an entirely separate set of rules to 
> work properly.
> 
>> On Jun 11, 2017, at 11:38 PM, Daryle Walker via swift-evolution 
>>  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. While there is precedent for this because of the 
>> "open" access control, I'd prefer if maybe we compromised and any @objc 
>> initializer is assumed to have the same performance characteristics as a 
>> factory initializer, without having to prepend the factory keyword.
>> • While I did initially propose the factory keyword, I'm still not entirely 
>> sure "factory" is the right choice. Though if the consensus that is the 
>> right keyword, then I'll happily accept that.
>> • Having "self" refer to the dynamic type of the returned instance 
>> seems...weird. While technically correct for a static method, I'd expect 
>> self to be an instance and Self to be the dynamic type just like any other 
>> initializer.
>> • Factory initializers should be used for any initializer that returns a 
>> value. Furthermore, I don't think we should limit factory initializers to 
>> just protocol extensions and classes. Sure it doesn't make sense for value 
>> types, but I don't think we should forbid that (and that way if you want to 
>> return a value instead of a assign to self, you'd just use factory 
>> intializer)
>> • I don't think there should be any delegating to other factory 
>> initializers. Nothing would stop you from returning a value initialized via 
>> another factory method, however.
>> 
>> Sorry if sounds a little rambled, don't have access to a computer for the 
>> rest of the day so typing this all up on my phone! 
>> 
>>> On Jun 11, 2017, at 1:39 PM, Gor Gyolchanyan via swift-evolution 
>>>  wrote:
>>> 
>>> 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, at 8:46 PM, Xiaodi Wu  wrote:
 
> On Sun, 

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

[Xiaodi Wu via swift-evolution]

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. While there is precedent for this because of the
> "open" access control, I'd prefer if maybe we compromised and any @objc
> initializer is assumed to have the same performance characteristics as a
> factory initializer, without having to prepend the factory keyword.
>

I'm not expert enough on Obj-C interop issues to make insightful comments
on this, but my naive impression here is that changing how _all_ Obj-C
initializers are imported by default seems...risky? Perhaps a summary of
how the compiler currently handles the issue is in order for this proposal,
so as to enable readers to evaluate this change.


> • While I did initially propose the factory keyword, I'm still not
> entirely sure "factory" is the right choice. Though if the consensus that
> is the right keyword, then I'll happily accept that.
> • Having "self" refer to the dynamic *type* of the returned instance
> seems...weird. While technically correct for a static method, I'd expect
> self to be an instance and Self to be the dynamic type just like any other
> initializer.
>

Agree: `self` referring to a type is unprecedented when it's not a static
method--this feels weird. If this is essential for the whole design, have
you considered maybe just calling it `static init`? (This raises a
potentially interesting thought about whether it'd make sense to also have
a `class init`...)

• Factory initializers should be used for *any *initializer that returns a
> value. Furthermore, I don't think we should limit factory initializers to
> just protocol extensions and classes. Sure it doesn't make sense for value
> types, but I don't think we should forbid that (and that way if you want to
> return a value instead of a assign to self, you'd just use factory
> intializer)
> • I don't think there should be *any* delegating to other factory
> initializers. Nothing would stop you from returning a value initialized via
> another factory method, however.
>

Hmm. That sounds workable and simpler, definitely.

Sorry if sounds a little rambled, don't have access to a computer for the
> rest of the day so typing this all up on my phone!
>
> On Jun 11, 2017, at 1:39 PM, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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, at 8:46 PM, Xiaodi Wu  wrote:
>
> 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 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  wrote:
>>
>> 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
>>> 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 

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

[Riley Testut via swift-evolution]

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 maybe we compromised and any @objc 
initializer is assumed to have the same performance characteristics as a 
factory initializer, without having to prepend the factory keyword.
• While I did initially propose the factory keyword, I'm still not entirely 
sure "factory" is the right choice. Though if the consensus that is the right 
keyword, then I'll happily accept that.
• Having "self" refer to the dynamic type of the returned instance 
seems...weird. While technically correct for a static method, I'd expect self 
to be an instance and Self to be the dynamic type just like any other 
initializer.
• Factory initializers should be used for any initializer that returns a value. 
Furthermore, I don't think we should limit factory initializers to just 
protocol extensions and classes. Sure it doesn't make sense for value types, 
but I don't think we should forbid that (and that way if you want to return a 
value instead of a assign to self, you'd just use factory intializer)
• I don't think there should be any delegating to other factory initializers. 
Nothing would stop you from returning a value initialized via another factory 
method, however.

Sorry if sounds a little rambled, don't have access to a computer for the rest 
of the day so typing this all up on my phone! 

> On Jun 11, 2017, at 1:39 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> 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, at 8:46 PM, Xiaodi Wu  wrote:
>> 
>>> 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 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  wrote:
 
> 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 
> 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 

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

[Gor Gyolchanyan via swift-evolution]

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, at 8:46 PM, Xiaodi Wu  wrote:
> 
> 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 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 > > wrote:
>> 
>> 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 
>> 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 >> > wrote:
>>> 
>>> 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?

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

[Charles Srstka via swift-evolution]

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 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 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, 2017, at 12:43 PM, Gor Gyolchanyan > > 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 >> > 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
>>>  
>>> 
>>>  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 
 > 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.
> 

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

[Michael Grewal via swift-evolution]

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 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, 2017, at 12:43 PM, Gor Gyolchanyan  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  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
>>  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 
  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.
 
>>> 
>>> 

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

[Xiaodi Wu via swift-evolution]

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

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

[Gor Gyolchanyan via swift-evolution]

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.

> On Jun 11, 2017, at 7:38 PM, Xiaodi Wu  wrote:
> 
> 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 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 > > wrote:
>> 
>> 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 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 

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

[Xiaodi Wu via swift-evolution]

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: ExpressibleByIntegerLiteral {
>
> public typealias IntegerLiteralType = UInt64
>
> public init(initegerLiteral literal: IntegerLiteralType) {
> self.uint64Value = literal // error: Cannot convert from
> IntegerLiteralType (a.k.a. Int) to UInt64
> }
>
> }
>
> It clearly preferred the global `IntegerLiteralType` over mine and
> replacing the signature with `(integerLiteral literal:
> Self.IntegerLiteralType)` fixed it.
> There have been numerous examples like this.
>

To my eye, this ought to be a bug. The general rule of thumb, as far as I
can tell, is that in Swift locals shadow globals (unless they override
them). I cannot see a justification for the behavior you show here. I'm
sure there's some good explanation for it, which I might have been able to
come up with once upon a time, but quite simply this is weird.

In any case, I think this is getting far afield of the topic at hand. Can I
suggest a separate thread here or in swift-users if you'd like to pursue
this topic?


> If you make a protocol, which you intend to fully automatically conform to
> another protocol (by implementing all its requirements in a protocol
> extension), this "conformance" can silently fail due to ambiguities like
> this and you won't catch it until you conform to this protocol and find a
> weird error.
> It's even more confusing in generic function constraints:
>
> extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A:
> ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
> return 42
> }
>
> Can you honestly say that from the first glance, it's immediately obvious
> to you which one of the `IntegerLiteralType ` this is referring to?
>
> Regarding access modifiers on extensions and `inout enum`, I agree: that's
> an unnecessary complication of the lexical structure that introduces a lot
> of confusion and provides very questionable gain.
>
> On Jun 11, 2017, at 11:43 AM, Adrian Zubarev  com> wrote:
>
> 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 if other people are using this convenience, I’ll
> let them have that option :-) , but I simply cannot get along with the idea
> that there could a global variable or a function that has the exact same
> signature as one of the type members, which could lead to unexpected bugs
> which are really hard to track.
>
> If I would granted the chance to tackle again the access modifier on
> extensions, I’d do it and try to remove that feature from the language. I’m
> not using it, I won’t ever use it and I haven’t seen any *good* swift code
> using it. It’s just too much sugar if you ask me.
>
> Same goes for indirect enum. How rare is it used? If it’s used how
> complex are the enum cases that it cannot be applied on the cases only
> which needs it?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com)
> schrieb:
>
> 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 to refer to globals and members in the same way is also
> making the code harder to read.
>
> The same goes for using `Self.` for associated types and type aliases
> inside protocols, because it's very easy to accidentally confuse them with
> global types, which would mess up the protocol.
> I know that this adds a bit of code, but it does not make the code less
> readable (in the contrary) and modern IDEs are very capable of code
> completion, which negates the problem of having to type more text manually.
>
> The argument agains this was something like "this is not worth sacrificing
> such a convenience".
> On the other hand, on numerous occasions I've heard another argument
> against a proposal that said "it's not worth gaining terseness by
> sacrificing clarity".
>
> This direct contradiction of priorities is worrying to me.
>
> On Jun 11, 2017, at 11:21 AM, Adrian Zubarev  com> 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 

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

[Xiaodi Wu via swift-evolution]

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
> 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  wrote:
>
> 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 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  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 <
>> swift-evolution@swift.org> 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 

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

[Gor Gyolchanyan via swift-evolution]

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 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 init(initegerLiteral literal: IntegerLiteralType) {
>   self.uint64Value = literal // error: Cannot convert from 
> IntegerLiteralType (a.k.a. Int) to UInt64
>   }
> 
> }
> 
> It clearly preferred the global `IntegerLiteralType` over mine and replacing 
> the signature with `(integerLiteral literal: Self.IntegerLiteralType)` fixed 
> it.
> There have been numerous examples like this.
> If you make a protocol, which you intend to fully automatically conform to 
> another protocol (by implementing all its requirements in a protocol 
> extension), this "conformance" can silently fail due to ambiguities like this 
> and you won't catch it until you conform to this protocol and find a weird 
> error.
> It's even more confusing in generic function constraints:
> 
> extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A: 
> ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
>   return 42
> }
> 
> Can you honestly say that from the first glance, it's immediately obvious to 
> you which one of the `IntegerLiteralType ` this is referring to?
> 
> Regarding access modifiers on extensions and `inout enum`, I agree: that's an 
> unnecessary complication of the lexical structure that introduces a lot of 
> confusion and provides very questionable gain.
> 
>> On Jun 11, 2017, at 11:43 AM, Adrian Zubarev 
>> > 
>> wrote:
>> 
>> 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 if other people are using this convenience, I’ll let 
>> them have that option :-) , but I simply cannot get along with the idea that 
>> there could a global variable or a function that has the exact same 
>> signature as one of the type members, which could lead to unexpected bugs 
>> which are really hard to track.
>> 
>> If I would granted the chance to tackle again the access modifier on 
>> extensions, I’d do it and try to remove that feature from the language. I’m 
>> not using it, I won’t ever use it and I haven’t seen any *good* swift code 
>> using it. It’s just too much sugar if you ask me.
>> 
>> Same goes for indirect enum. How rare is it used? If it’s used how complex 
>> are the enum cases that it cannot be applied on the cases only which needs 
>> it?
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com 
>> ) schrieb:
>> 
>>> 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 to refer to globals and members in the same way is also 
>>> making the code harder to read.
>>> 
>>> The same goes for using `Self.` for associated types and type aliases 
>>> inside protocols, because it's very easy to accidentally confuse them with 
>>> global types, which would mess up the protocol.
>>> I know that this adds a bit of code, but it does not make the code less 
>>> readable (in the contrary) and modern IDEs are very capable of code 
>>> completion, which negates the problem of having to type more text manually.
>>> 
>>> The argument agains this was something like "this is not worth sacrificing 
>>> such a convenience".
>>> On the other hand, on numerous occasions I've heard another argument 
>>> against a proposal that said "it's not worth gaining terseness by 
>>> sacrificing clarity".
>>> 
>>> This direct contradiction of priorities is worrying to me.
>>> 
 On Jun 11, 2017, at 11:21 AM, Adrian Zubarev 
 > 
 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 

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

[Gor Gyolchanyan via swift-evolution]

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 be ambiguous 
every time.

*OR*

Make the unqualified access *always* prefer the most local (the most nested) 
scope every time and require qualified access to more global declarations. The 
downside of this is the need to fuly qualify the name (sometimes, even by the 
module name), so a simple syntax sugar would help.
I'm thinking something like a token that means "the outer scope of this scope" 
that you can use instead of fully qualifying the outer scope.

> On Jun 11, 2017, at 12:10 PM, Adrian Zubarev 
>  wrote:
> 
> 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 11:08:34, Adrian Zubarev (adrian.zuba...@devandartist.com 
> ) schrieb:
> 
>> 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 
>> otherwise to refer to something global if the local entity would be 
>> preferred? On the other hand if you run into such issues you can still tell 
>> explicitly that you wish to use local values.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 11. Juni 2017 um 10:56:47, Gor Gyolchanyan (g...@gyolchanyan.com 
>> ) schrieb:
>> 
>>> 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 init(initegerLiteral literal: IntegerLiteralType) {
>>> self.uint64Value = literal // error: Cannot convert from IntegerLiteralType 
>>> (a.k.a. Int) to UInt64
>>> }
>>> 
>>> }
>>> 
>>> It clearly preferred the global `IntegerLiteralType` over mine and 
>>> replacing the signature with `(integerLiteral literal: 
>>> Self.IntegerLiteralType)` fixed it.
>>> There have been numerous examples like this.
>>> If you make a protocol, which you intend to fully automatically conform to 
>>> another protocol (by implementing all its requirements in a protocol 
>>> extension), this "conformance" can silently fail due to ambiguities like 
>>> this and you won't catch it until you conform to this protocol and find a 
>>> weird error.
>>> It's even more confusing in generic function constraints:
>>> 
>>> extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A: 
>>> ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
>>> return 42
>>> }
>>> 
>>> Can you honestly say that from the first glance, it's immediately obvious 
>>> to you which one of the `IntegerLiteralType ` this is referring to?
>>> 
>>> Regarding access modifiers on extensions and `inout enum`, I agree: that's 
>>> an unnecessary complication of the lexical structure that introduces a lot 
>>> of confusion and provides very questionable gain.
>>> 
 On Jun 11, 2017, at 11:43 AM, Adrian Zubarev 
 > 
 wrote:
 
 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 if other people are using this convenience, I’ll 
 let them have that option :-) , but I simply cannot get along with the 
 idea that there could a global variable or a function that has the exact 
 same signature as one of the type members, which could lead to unexpected 
 bugs which are really hard to track.
 
 If I would granted the chance to tackle again the access modifier on 
 extensions, I’d do it and try to remove that feature from the language. 
 I’m not using it, I won’t ever use it and I haven’t seen any *good* swift 
 code using it. It’s just too much sugar if you ask me.
 
 Same goes for indirect enum. How rare is it used? If it’s used how complex 
 are the enum cases that it cannot be applied on the cases only which needs 
 it?
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 

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

[Xiaodi Wu via swift-evolution]

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 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  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 <
> swift-evolution@swift.org> 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 (g...@gyolchanyan.com)
>> 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 <
>> swift-evolution@swift.org> 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 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 (
>> swift-evolution@swift.org) 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/-factory-initializers.md
>>
>> On Jun 10, 2017, at 

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

[Gor Gyolchanyan via swift-evolution]

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 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 
> > 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 (g...@gyolchanyan.com 
> ) 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 
>>> > 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 
>>>  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 
>>> (swift-evolution@swift.org ) 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/-factory-initializers.md
  
 
> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan  > 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 

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

[Gor Gyolchanyan via swift-evolution]

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 init(initegerLiteral literal: IntegerLiteralType) {
self.uint64Value = literal // error: Cannot convert from 
IntegerLiteralType (a.k.a. Int) to UInt64
}

}

It clearly preferred the global `IntegerLiteralType` over mine and replacing 
the signature with `(integerLiteral literal: Self.IntegerLiteralType)` fixed it.
There have been numerous examples like this.
If you make a protocol, which you intend to fully automatically conform to 
another protocol (by implementing all its requirements in a protocol 
extension), this "conformance" can silently fail due to ambiguities like this 
and you won't catch it until you conform to this protocol and find a weird 
error.
It's even more confusing in generic function constraints:

extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A: 
ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
return 42
}

Can you honestly say that from the first glance, it's immediately obvious to 
you which one of the `IntegerLiteralType ` this is referring to?

Regarding access modifiers on extensions and `inout enum`, I agree: that's an 
unnecessary complication of the lexical structure that introduces a lot of 
confusion and provides very questionable gain.

> On Jun 11, 2017, at 11:43 AM, Adrian Zubarev 
>  wrote:
> 
> 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 if other people are using this convenience, I’ll let 
> them have that option :-) , but I simply cannot get along with the idea that 
> there could a global variable or a function that has the exact same signature 
> as one of the type members, which could lead to unexpected bugs which are 
> really hard to track.
> 
> If I would granted the chance to tackle again the access modifier on 
> extensions, I’d do it and try to remove that feature from the language. I’m 
> not using it, I won’t ever use it and I haven’t seen any *good* swift code 
> using it. It’s just too much sugar if you ask me.
> 
> Same goes for indirect enum. How rare is it used? If it’s used how complex 
> are the enum cases that it cannot be applied on the cases only which needs it?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com 
> ) schrieb:
> 
>> 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 to refer to globals and members in the same way is also making 
>> the code harder to read.
>> 
>> The same goes for using `Self.` for associated types and type aliases inside 
>> protocols, because it's very easy to accidentally confuse them with global 
>> types, which would mess up the protocol.
>> I know that this adds a bit of code, but it does not make the code less 
>> readable (in the contrary) and modern IDEs are very capable of code 
>> completion, which negates the problem of having to type more text manually.
>> 
>> The argument agains this was something like "this is not worth sacrificing 
>> such a convenience".
>> On the other hand, on numerous occasions I've heard another argument against 
>> a proposal that said "it's not worth gaining terseness by sacrificing 
>> clarity".
>> 
>> This direct contradiction of priorities is worrying to me.
>> 
>>> On Jun 11, 2017, at 11:21 AM, Adrian Zubarev 
>>> > 
>>> 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
>>> 

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

[Adrian Zubarev via swift-evolution]

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 if other people are using this convenience, I’ll let 
them have that option :-) , but I simply cannot get along with the idea that 
there could a global variable or a function that has the exact same signature 
as one of the type members, which could lead to unexpected bugs which are 
really hard to track.

If I would granted the chance to tackle again the access modifier on 
extensions, I’d do it and try to remove that feature from the language. I’m not 
using it, I won’t ever use it and I haven’t seen any *good* swift code using 
it. It’s just too much sugar if you ask me.

Same goes for indirect enum. How rare is it used? If it’s used how complex are 
the enum cases that it cannot be applied on the cases only which needs it?



-- 
Adrian Zubarev
Sent with Airmail

Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com) schrieb:

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 to refer to globals and members in the same way is also making 
the code harder to read.

The same goes for using `Self.` for associated types and type aliases inside 
protocols, because it's very easy to accidentally confuse them with global 
types, which would mess up the protocol.
I know that this adds a bit of code, but it does not make the code less 
readable (in the contrary) and modern IDEs are very capable of code completion, 
which negates the problem of having to type more text manually.

The argument agains this was something like "this is not worth sacrificing such 
a convenience".
On the other hand, on numerous occasions I've heard another argument against a 
proposal that said "it's not worth gaining terseness by sacrificing clarity".

This direct contradiction of priorities is worrying to me.

On Jun 11, 2017, at 11:21 AM, Adrian Zubarev  
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 (g...@gyolchanyan.com) 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 
 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 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?

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

[Adrian Zubarev via swift-evolution]

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 11:08:34, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

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 
otherwise to refer to something global if the local entity would be preferred? 
On the other hand if you run into such issues you can still tell explicitly 
that you wish to use local values.



-- 
Adrian Zubarev
Sent with Airmail

Am 11. Juni 2017 um 10:56:47, Gor Gyolchanyan (g...@gyolchanyan.com) schrieb:

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 init(initegerLiteral literal: IntegerLiteralType) {
self.uint64Value = literal // error: Cannot convert from IntegerLiteralType 
(a.k.a. Int) to UInt64
}

}

It clearly preferred the global `IntegerLiteralType` over mine and replacing 
the signature with `(integerLiteral literal: Self.IntegerLiteralType)` fixed it.
There have been numerous examples like this.
If you make a protocol, which you intend to fully automatically conform to 
another protocol (by implementing all its requirements in a protocol 
extension), this "conformance" can silently fail due to ambiguities like this 
and you won't catch it until you conform to this protocol and find a weird 
error.
It's even more confusing in generic function constraints:

extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A: 
ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
return 42
}

Can you honestly say that from the first glance, it's immediately obvious to 
you which one of the `IntegerLiteralType ` this is referring to?

Regarding access modifiers on extensions and `inout enum`, I agree: that's an 
unnecessary complication of the lexical structure that introduces a lot of 
confusion and provides very questionable gain.

On Jun 11, 2017, at 11:43 AM, Adrian Zubarev  
wrote:

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 if other people are using this convenience, I’ll let 
them have that option :-) , but I simply cannot get along with the idea that 
there could a global variable or a function that has the exact same signature 
as one of the type members, which could lead to unexpected bugs which are 
really hard to track.

If I would granted the chance to tackle again the access modifier on 
extensions, I’d do it and try to remove that feature from the language. I’m not 
using it, I won’t ever use it and I haven’t seen any *good* swift code using 
it. It’s just too much sugar if you ask me.

Same goes for indirect enum. How rare is it used? If it’s used how complex are 
the enum cases that it cannot be applied on the cases only which needs it?




-- 
Adrian Zubarev
Sent with Airmail

Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com) schrieb:

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 to refer to globals and members in the same way is also making 
the code harder to read.

The same goes for using `Self.` for associated types and type aliases inside 
protocols, because it's very easy to accidentally confuse them with global 
types, which would mess up the protocol.
I know that this adds a bit of code, but it does not make the code less 
readable (in the contrary) and modern IDEs are very capable of code completion, 
which negates the problem of having to type more text manually.

The argument agains this was something like "this is not worth sacrificing such 
a convenience".
On the other hand, on numerous occasions I've heard another argument against a 
proposal that said "it's not worth gaining terseness by sacrificing clarity".

This direct contradiction of priorities is worrying to me.

On Jun 11, 2017, at 11:21 AM, Adrian Zubarev  
wrote:

Yeah, well I messed up my proposal from last year about removing the access 
modifier 

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

[Adrian Zubarev via swift-evolution]

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 
otherwise to refer to something global if the local entity would be preferred? 
On the other hand if you run into such issues you can still tell explicitly 
that you wish to use local values.



-- 
Adrian Zubarev
Sent with Airmail

Am 11. Juni 2017 um 10:56:47, Gor Gyolchanyan (g...@gyolchanyan.com) schrieb:

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 init(initegerLiteral literal: IntegerLiteralType) {
self.uint64Value = literal // error: Cannot convert from IntegerLiteralType 
(a.k.a. Int) to UInt64
}

}

It clearly preferred the global `IntegerLiteralType` over mine and replacing 
the signature with `(integerLiteral literal: Self.IntegerLiteralType)` fixed it.
There have been numerous examples like this.
If you make a protocol, which you intend to fully automatically conform to 
another protocol (by implementing all its requirements in a protocol 
extension), this "conformance" can silently fail due to ambiguities like this 
and you won't catch it until you conform to this protocol and find a weird 
error.
It's even more confusing in generic function constraints:

extension theUltimateAnswerToLifeUniverseAndEverything() -> A where A: 
ExpressibleByIntegerLiteral, IntegerLiteralType == IntMax {
return 42
}

Can you honestly say that from the first glance, it's immediately obvious to 
you which one of the `IntegerLiteralType ` this is referring to?

Regarding access modifiers on extensions and `inout enum`, I agree: that's an 
unnecessary complication of the lexical structure that introduces a lot of 
confusion and provides very questionable gain.

On Jun 11, 2017, at 11:43 AM, Adrian Zubarev  
wrote:

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 if other people are using this convenience, I’ll let 
them have that option :-) , but I simply cannot get along with the idea that 
there could a global variable or a function that has the exact same signature 
as one of the type members, which could lead to unexpected bugs which are 
really hard to track.

If I would granted the chance to tackle again the access modifier on 
extensions, I’d do it and try to remove that feature from the language. I’m not 
using it, I won’t ever use it and I haven’t seen any *good* swift code using 
it. It’s just too much sugar if you ask me.

Same goes for indirect enum. How rare is it used? If it’s used how complex are 
the enum cases that it cannot be applied on the cases only which needs it?




-- 
Adrian Zubarev
Sent with Airmail

Am 11. Juni 2017 um 10:30:29, Gor Gyolchanyan (g...@gyolchanyan.com) schrieb:

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 to refer to globals and members in the same way is also making 
the code harder to read.

The same goes for using `Self.` for associated types and type aliases inside 
protocols, because it's very easy to accidentally confuse them with global 
types, which would mess up the protocol.
I know that this adds a bit of code, but it does not make the code less 
readable (in the contrary) and modern IDEs are very capable of code completion, 
which negates the problem of having to type more text manually.

The argument agains this was something like "this is not worth sacrificing such 
a convenience".
On the other hand, on numerous occasions I've heard another argument against a 
proposal that said "it's not worth gaining terseness by sacrificing clarity".

This direct contradiction of priorities is worrying to me.

On Jun 11, 2017, at 11:21 AM, Adrian Zubarev  
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 

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

[Xiaodi Wu via swift-evolution]

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 <
swift-evolution@swift.org> 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 (g...@gyolchanyan.com)
> 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 <
> swift-evolution@swift.org> 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 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 (
> swift-evolution@swift.org) 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/-factory-initializers.md
>
> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan  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  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
>  Originally I used the 

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

[Gor Gyolchanyan via swift-evolution]

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?

> On Jun 11, 2017, at 5:53 PM, Xiaodi Wu  wrote:
> 
> 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 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 > > 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 
>> > 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 (g...@gyolchanyan.com 
>> ) 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.

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

[Gor Gyolchanyan via swift-evolution]

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 to refer to globals and members in the same way is also making 
the code harder to read.

The same goes for using `Self.` for associated types and type aliases inside 
protocols, because it's very easy to accidentally confuse them with global 
types, which would mess up the protocol.
I know that this adds a bit of code, but it does not make the code less 
readable (in the contrary) and modern IDEs are very capable of code completion, 
which negates the problem of having to type more text manually.

The argument agains this was something like "this is not worth sacrificing such 
a convenience".
On the other hand, on numerous occasions I've heard another argument against a 
proposal that said "it's not worth gaining terseness by sacrificing clarity".

This direct contradiction of priorities is worrying to me.

> On Jun 11, 2017, at 11:21 AM, Adrian Zubarev 
>  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 (g...@gyolchanyan.com 
> ) 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 
>>> > 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 
>>>  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 
>>> (swift-evolution@swift.org ) 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/-factory-initializers.md
  
 
> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan  > wrote:
> 
> Hi, Riley!
> 
> I 

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

[Adrian Zubarev via swift-evolution]

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 (g...@gyolchanyan.com) 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 
 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 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 
(swift-evolution@swift.org) 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/-factory-initializers.md

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


This is a very interesting read.

Thanks you! I tried to make it as clear and detailed as 

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

[Gor Gyolchanyan via swift-evolution]

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 
>  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 
>  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 
> (swift-evolution@swift.org ) 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/-factory-initializers.md
>>  
>> 
>>> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan >> > 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 > 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
  
 
  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 
> > wrote:
> 
>> 
>> This is a very interesting read.
>> 
> 
> Thanks you! I tried to make it as clear and detailed as possible.  
> 
>> 
>> We did not 

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

[Adrian Zubarev via swift-evolution]

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 : 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 
(swift-evolution@swift.org) 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/-factory-initializers.md

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

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

[Gor Gyolchanyan via swift-evolution]

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 initializer is pretty much 
a normal static function which doesn't need any guarantees at all, so it could 
get the instance from wherever it wanted. I can't say I'm totally sure about 
this, but it seems like limiting the overridability wouldn't server any real 
purpose.

I initially decided to include the Objective-C/C part because the current 
behavior of imported initializers exactly matches that of an indirect 
initializer, so if these changes would be made, *all* non-indirect initializers 
(both native and imported) would have static typing guarantees that could be 
exploited by the compiler. I don't think it's critical, because Swift is now at 
the brink of major version 4 and this odd imported initializer behavior hasn't 
seemed to have caused any trouble. Still, I think as a sneak peek at a future 
proposal to clean up the imported initializers would be warranted as a 
side-note in this proposal for the core team to get a better understanding of 
where this could go.

About the formulation: I'm just being overly pedantic about everything as 
usual. I just thought that the core team would prefer something more like a 
spec document, rather then a favor. It's really the least important aspect at 
this point, so it's fine 

> On Jun 11, 2017, at 1:54 AM, Riley Testut  wrote:
> 
> 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 same 
> signature as its superclass' convenience method. The only difference is it 
> can't call the super initializer. I think this *does* make the most sense, 
> because I'm not sure super.init for an indirect initializer makes much sense, 
> and if you really wanted to do that, you could just call the initializer 
> directly (aka "let superReturnValue = Type()). But happy to change if you 
> feel strongly it should be allowed!
> 
> I left out the Objective-C/C interoperability aspects because IMO they aren't 
> necessary for this proposal. This proposal is specifically limited to adding 
> a new indirect initializer to Swift. I could mention that it would be exposed 
> to Objective-C just like other initializers, but anything more than that I 
> think should be a separate proposal (such as how C/Objective-C initializers 
> would be imported).
> 
> Also, what parts sound like a personal letter? The motivation + examples are 
> motivated by personal experience, and so I wrote them from my perspective 
> (similar to other proposals), but the proposed solution + detailed design 
> should be straightforward and void of opinions. 
> 
> On Jun 10, 2017, at 5:25 PM, Gor Gyolchanyan  > wrote:
> 
>> 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 specification of implementation details that I 
>> provided as well as C/Objective-C interoperability changes.
>> * The proposal is formulated more like a personal opinion, rather then a 
>> formal specification. It sounds like a personal letter. I'd recommend 
>> writing it similarly as you'd write a wikipedia page.
>> 
>>> On Jun 11, 2017, at 1:12 AM, Riley Testut >> > wrote:
>>> 
>>> 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, 2017, at 12:43 PM, Gor Gyolchanyan > 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, 

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

[Riley Testut via swift-evolution]

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 same 
signature as its superclass' convenience method. The only difference is it 
can't call the super initializer. I think this *does* make the most sense, 
because I'm not sure super.init for an indirect initializer makes much sense, 
and if you really wanted to do that, you could just call the initializer 
directly (aka "let superReturnValue = Type()). But happy to change if you feel 
strongly it should be allowed!

I left out the Objective-C/C interoperability aspects because IMO they aren't 
necessary for this proposal. This proposal is specifically limited to adding a 
new indirect initializer to Swift. I could mention that it would be exposed to 
Objective-C just like other initializers, but anything more than that I think 
should be a separate proposal (such as how C/Objective-C initializers would be 
imported).

Also, what parts sound like a personal letter? The motivation + examples are 
motivated by personal experience, and so I wrote them from my perspective 
(similar to other proposals), but the proposed solution + detailed design 
should be straightforward and void of opinions. 

> On Jun 10, 2017, at 5:25 PM, Gor Gyolchanyan  wrote:
> 
> 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 specification of implementation details that I 
> provided as well as C/Objective-C interoperability changes.
> * The proposal is formulated more like a personal opinion, rather then a 
> formal specification. It sounds like a personal letter. I'd recommend writing 
> it similarly as you'd write a wikipedia page.
> 
>> On Jun 11, 2017, at 1:12 AM, Riley Testut  wrote:
>> 
>> 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, 2017, at 12:43 PM, Gor Gyolchanyan  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  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
  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 
>>  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 

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

[Gor Gyolchanyan via swift-evolution]

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 specification of implementation details that I 
provided as well as C/Objective-C interoperability changes.
* The proposal is formulated more like a personal opinion, rather then a formal 
specification. It sounds like a personal letter. I'd recommend writing it 
similarly as you'd write a wikipedia page.

> On Jun 11, 2017, at 1:12 AM, Riley Testut  wrote:
> 
> 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, 2017, at 12:43 PM, Gor Gyolchanyan > > 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 >> > 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
>>>  
>>> 
>>>  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 
 > 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, 

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

[Riley Testut via swift-evolution]

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

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

[Gor Gyolchanyan via swift-evolution]

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

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

[Riley Testut via swift-evolution]

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
 

 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 
>  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 
>> > wrote:
>> 
>> 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 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. 

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

[Gor Gyolchanyan via swift-evolution]

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

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

[Xiaodi Wu via swift-evolution]

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 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  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  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  wrote:
>>
>> 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 `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 

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

[Gor Gyolchanyan via swift-evolution]

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 something or composed it 
wrong, so please feel free to comment, fork and send pull requests. 

> On Jun 9, 2017, at 3:24 PM, Xiaodi Wu  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  > 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 > > wrote:
>> 
>> 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 `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 

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

[Xiaodi Wu via swift-evolution]

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, 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  wrote:
>
> 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 `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  wrote:
>>
>>
>> On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan  wrote:
>>
>>> I think a good approach 

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

[Gor Gyolchanyan via swift-evolution]

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  wrote:
> 
> 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 `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 > > wrote:
>> 
>> 
>> 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 
>> 

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

[Xiaodi Wu via swift-evolution]

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 `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  wrote:
>
>
> 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 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  wrote:
>>
>>
>> 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 

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

[Gor Gyolchanyan via swift-evolution]

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

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

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

[Xiaodi Wu via swift-evolution]

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

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

[Xiaodi Wu via swift-evolution]

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
> 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  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 <
> swift-evolution@swift.org> 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

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

[Gor Gyolchanyan via swift-evolution]

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.

> On Jun 9, 2017, at 2:07 PM, Xiaodi Wu  wrote:
> 
> 
> 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 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 > > 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 

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

[Gor Gyolchanyan via swift-evolution]

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

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

[Xiaodi Wu via swift-evolution]

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 <
swift-evolution@swift.org> 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  wrote:
>
>
> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> 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 gpar...@apple.com Runtime Wrangler
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gor Gyolchanyan via swift-evolution]

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  wrote:
> 
> 
>> 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 `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 gpar...@apple.com  Runtime 
> Wrangler
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> 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 `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 gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 (g...@gyolchanyan.com) schrieb:

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 8, 2017, at 6:45 PM, Adrian Zubarev  
wrote:

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 create a custom UIView in a nib file then instead of assigning it to a 
UIViewController they nest it in another container view, which is not what it’s 
meant for in the first place. Factory initializer could solve this issue by 
simply assigning the instance created from a nib file to self. The nested view 
hierarchy would disappear and it won’t be that much of an abuse anymore. 




-- 
Adrian Zubarev
Sent with Airmail

Am 8. Juni 2017 um 14:09:30, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

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

2. Arbitrary `return` Statements In Intializers

The second idea is to allow `return ...` inside all initializers, which should 
also, theoretically, be a simple rewrite to `self = ...; return`. This one is 
to complement the existing `return nil` and allow some super-short initializers 
with a switch that returns in all cases or a more complex initializer that has 
a lot of guard statements.

2.1. Future Factory Initializers

In addition, the `return ...` syntax has the benefit for potential factory 
initializers. So far, the proposals for factory initializers involved a keyword 
attached to the initializer, which just complicates the lexical structure of 
the language and adds unnecessary complication to the interface of types. 
Currently, factory initializers imported from Objective-C or from C using the 
`__attribute__((swift_name("MyType.init(self:...)")))` look like normal 
initializers (an in case of C, the return value doesn't even have to be related 
to the enclosing type in any way), but behave as you'd expect: you call the 
initializer and the result is a value that *should* be a subtype of the type 
you've called the initializer for. So, if in the future Swift gets native 
factory initializers (including, most importantly, in protocols), it won't 
require special syntax, because simply returning an instance of a subtype (with 
a compile-time check, of course) would look and behave very intuitively. This 
would also be very useful for singletons, which would use a private initializer 
for creating the instance and a public factory initializer for returning it.

3. Failable Member Initialization

The third idea is to allow writing `self.member = MemberType?(...)` or 
`self.member = .init?(...)` (the exact syntax is up to debate) inside failable 
initializers, which would be simply rewritten as:

guard let _self_member = MemberType(...) else {
return nil
}
self.member = _self_member

This will dramatically reduce the boilerplate and visual clutter form complex 
failable initializers that call other failable initializers. A good use case 
would be complex `LosslessStringConvertible` types with many 
`LosslessStringConvertible` members.

So, what do you guys think?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 create a custom UIView in a nib file then instead of assigning it to a 
UIViewController they nest it in another container view, which is not what it’s 
meant for in the first place. Factory initializer could solve this issue by 
simply assigning the instance created from a nib file to self. The nested view 
hierarchy would disappear and it won’t be that much of an abuse anymore.



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Juni 2017 um 14:09:30, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

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

2. Arbitrary `return` Statements In Intializers

The second idea is to allow `return ...` inside all initializers, which should 
also, theoretically, be a simple rewrite to `self = ...; return`. This one is 
to complement the existing `return nil` and allow some super-short initializers 
with a switch that returns in all cases or a more complex initializer that has 
a lot of guard statements.

2.1. Future Factory Initializers

In addition, the `return ...` syntax has the benefit for potential factory 
initializers. So far, the proposals for factory initializers involved a keyword 
attached to the initializer, which just complicates the lexical structure of 
the language and adds unnecessary complication to the interface of types. 
Currently, factory initializers imported from Objective-C or from C using the 
`__attribute__((swift_name("MyType.init(self:...)")))` look like normal 
initializers (an in case of C, the return value doesn't even have to be related 
to the enclosing type in any way), but behave as you'd expect: you call the 
initializer and the result is a value that *should* be a subtype of the type 
you've called the initializer for. So, if in the future Swift gets native 
factory initializers (including, most importantly, in protocols), it won't 
require special syntax, because simply returning an instance of a subtype (with 
a compile-time check, of course) would look and behave very intuitively. This 
would also be very useful for singletons, which would use a private initializer 
for creating the instance and a public factory initializer for returning it.

3. Failable Member Initialization

The third idea is to allow writing `self.member = MemberType?(...)` or 
`self.member = .init?(...)` (the exact syntax is up to debate) inside failable 
initializers, which would be simply rewritten as:

guard let _self_member = MemberType(...) else {
return nil
}
self.member = _self_member

This will dramatically reduce the boilerplate and visual clutter form complex 
failable initializers that call other failable initializers. A good use case 
would be complex `LosslessStringConvertible` types with many 
`LosslessStringConvertible` members.

So, what do you guys think?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gor Gyolchanyan via swift-evolution]

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 polymorphism might be used 
to do things like in-place initialization when assigning to a variable or stuff 
like that. Factory initializers would break that logic and would require some 
additional compiler awareness, so as much as I'd love to have factory 
initializers, It doesn't look like it's as easy as adding syntax for it.

> On Jun 8, 2017, at 6:53 PM, Adrian Zubarev  
> wrote:
> 
> 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 (g...@gyolchanyan.com 
> ) schrieb:
> 
>> 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 8, 2017, at 6:45 PM, Adrian Zubarev >> > wrote:
>>> 
>>> 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 create a custom UIView in a nib file then instead of 
>>> assigning it to a UIViewController they nest it in another container view, 
>>> which is not what it’s meant for in the first place. Factory initializer 
>>> could solve this issue by simply assigning the instance created from a nib 
>>> file to self. The nested view hierarchy would disappear and it won’t be 
>>> that much of an abuse anymore. 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 8. Juni 2017 um 14:09:30, Gor Gyolchanyan via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 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 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.
 
 2. Arbitrary `return` Statements In Intializers
 
 The second idea is to allow `return ...` inside all initializers, which 
 should also, theoretically, be a simple rewrite to `self = ...; return`. 
 This one is to complement the existing `return nil` and allow some 
 super-short initializers with a switch that returns in all cases or a more 
 complex initializer that has a lot of guard statements.
 
 2.1. Future Factory Initializers
 
 In addition, the `return ...` syntax has the benefit for potential factory 
 initializers. So far, the proposals for factory initializers involved a 
 keyword attached to the initializer, which just complicates the lexical 
 structure of the language and adds unnecessary complication to the 
 interface of types. Currently, factory initializers imported from 
 Objective-C or from C using the 
 `__attribute__((swift_name("MyType.init(self:...)")))` look like normal 
 initializers (an in case of C, the return value doesn't even have to be 
 related to the enclosing type in any way), but behave as you'd expect: you 
 call the initializer and the result is a value that *should* be a subtype 
 of the type you've called the initializer for. So, if in the future Swift 
 gets native factory initializers (including, most importantly, in 
 protocols), it won't require special syntax, because simply returning an 
 instance of a subtype (with a compile-time check, of course) would look 
 and behave very intuitively. This would also 

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

[Gor Gyolchanyan via swift-evolution]

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 8, 2017, at 6:45 PM, Adrian Zubarev  
> wrote:
> 
> 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 create a custom UIView in a nib file then instead of assigning it to 
> a UIViewController they nest it in another container view, which is not what 
> it’s meant for in the first place. Factory initializer could solve this issue 
> by simply assigning the instance created from a nib file to self. The nested 
> view hierarchy would disappear and it won’t be that much of an abuse anymore. 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Juni 2017 um 14:09:30, Gor Gyolchanyan via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 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 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.
>> 
>> 2. Arbitrary `return` Statements In Intializers
>> 
>> The second idea is to allow `return ...` inside all initializers, which 
>> should also, theoretically, be a simple rewrite to `self = ...; return`. 
>> This one is to complement the existing `return nil` and allow some 
>> super-short initializers with a switch that returns in all cases or a more 
>> complex initializer that has a lot of guard statements.
>> 
>> 2.1. Future Factory Initializers
>> 
>> In addition, the `return ...` syntax has the benefit for potential factory 
>> initializers. So far, the proposals for factory initializers involved a 
>> keyword attached to the initializer, which just complicates the lexical 
>> structure of the language and adds unnecessary complication to the interface 
>> of types. Currently, factory initializers imported from Objective-C or from 
>> C using the `__attribute__((swift_name("MyType.init(self:...)")))` look like 
>> normal initializers (an in case of C, the return value doesn't even have to 
>> be related to the enclosing type in any way), but behave as you'd expect: 
>> you call the initializer and the result is a value that *should* be a 
>> subtype of the type you've called the initializer for. So, if in the future 
>> Swift gets native factory initializers (including, most importantly, in 
>> protocols), it won't require special syntax, because simply returning an 
>> instance of a subtype (with a compile-time check, of course) would look and 
>> behave very intuitively. This would also be very useful for singletons, 
>> which would use a private initializer for creating the instance and a public 
>> factory initializer for returning it.
>> 
>> 3. Failable Member Initialization
>> 
>> The third idea is to allow writing `self.member = MemberType?(...)` or 
>> `self.member = .init?(...)` (the exact syntax is up to debate) inside 
>> failable initializers, which would be simply rewritten as:
>> 
>> guard let _self_member = MemberType(...) else {
>> return nil
>> }
>> self.member = _self_member
>> 
>> This will dramatically reduce the boilerplate and visual clutter form 
>> complex failable initializers that call other failable initializers. A good 
>> use case would be complex `LosslessStringConvertible` types with many 
>> `LosslessStringConvertible` members.
>> 
>> So, what do you guys think?
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gor Gyolchanyan via swift-evolution]

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, Gor Gyolchanyan  wrote:
> 
> 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 be nice to be able to use the same general 
> syntax to initializing members?
> The primary use case is to be able to avoid extra allocations and copies 
> (especially for large structures).
> It would look a lot like constructors in C++, where you have an opportunity 
> to directly initialize members in-place, except it won't be mandatory in case 
> the member is not default-initializable.
> Here's an example of what I imagine it could look like:
> 
> init() {
>   self.myHeavyDutyMember1.init(...)
>   self.myHeavyDutyMember2.init(...)
> }
> 
> The rule would be that if a direct member initializer call is present in an 
> initializer, no access to the member is allowed before that call and no other 
> direct member initializer calls on the same member are allowed, even if the 
> member is mutable.
> 
> Also also, something else just occurred to me:
> 
> Currently Optional and ImplicitlyUnwrappedOptional are the only 
> default-initializable types in Swift and that's compiler magic.
> Wouldn't it be nice to have a DefaultInitializable protocol that the compiler 
> would pick up on and treat the conforming type just like it does optionals? 
> All the same initialization rules would apply.
> 
> protocol DefaultInitializable {
> 
>   init()
> 
> }
> 
> An added benefit is how beautifully this would work with classes, where this 
> will be a `required init`, meaning that subclasses will be forced to also be 
> default-initializable, thus providing consistent polymorphic behavior that 
> will make the initializability guarantees possible. 
> 
>> On Jun 8, 2017, at 6:00 PM, Charles Srstka  wrote:
>> 
>>> 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 things to self can already be done with structs and enums:
>> 
>> struct S {
>>  let foo: String
>>  
>>  init(foo: String) {
>>  self.foo = foo
>>  }
>>  
>>  init(bar: String) {
>>  self = S(foo: bar) // works fine
>>  }
>> }
>> 
>> enum E {
>>  case foo
>>  case bar
>>  
>>  init(isFoo: Bool) {
>>  if isFoo {
>>  self = .foo // works fine
>>  } else {
>>  self = .bar // ditto
>>  }
>>  }
>> }
>> 
>> The one restriction is that in the case of the struct, you can’t have 
>> initialized any of the immutable properties before assigning to self.
>> 
>> struct S {
>>  let foo: String
>>  
>>  init(foo: String) {
>>  self.foo = foo
>>  }
>>  
>>  init(bar: String) {
>>  self.foo = "Foo"
>>  self = S(foo: bar) // error: immutable value 'self.foo' may 
>> only be initialized once
>>  }
>> }
>> 
>> The only real thing being proposed here, as I see it, is to make this 
>> behavior conceptually consistent with classes. Anything that simplifies the 
>> rather Byzantine rules surrounding initializers, while simultaneously 
>> enabling factory initializers, is a win in my book.
>> 
>> Charles
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gor Gyolchanyan via swift-evolution]

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 be nice to be able to use the same general syntax 
to initializing members?
The primary use case is to be able to avoid extra allocations and copies 
(especially for large structures).
It would look a lot like constructors in C++, where you have an opportunity to 
directly initialize members in-place, except it won't be mandatory in case the 
member is not default-initializable.
Here's an example of what I imagine it could look like:

init() {
self.myHeavyDutyMember1.init(...)
self.myHeavyDutyMember2.init(...)
}

The rule would be that if a direct member initializer call is present in an 
initializer, no access to the member is allowed before that call and no other 
direct member initializer calls on the same member are allowed, even if the 
member is mutable.

Also also, something else just occurred to me:

Currently Optional and ImplicitlyUnwrappedOptional are the only 
default-initializable types in Swift and that's compiler magic.
Wouldn't it be nice to have a DefaultInitializable protocol that the compiler 
would pick up on and treat the conforming type just like it does optionals? All 
the same initialization rules would apply.

protocol DefaultInitializable {

init()

}

An added benefit is how beautifully this would work with classes, where this 
will be a `required init`, meaning that subclasses will be forced to also be 
default-initializable, thus providing consistent polymorphic behavior that will 
make the initializability guarantees possible. 

> On Jun 8, 2017, at 6:00 PM, Charles Srstka  wrote:
> 
>> 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 things to self can already be done with structs and enums:
> 
> struct S {
>   let foo: String
>   
>   init(foo: String) {
>   self.foo = foo
>   }
>   
>   init(bar: String) {
>   self = S(foo: bar) // works fine
>   }
> }
> 
> enum E {
>   case foo
>   case bar
>   
>   init(isFoo: Bool) {
>   if isFoo {
>   self = .foo // works fine
>   } else {
>   self = .bar // ditto
>   }
>   }
> }
> 
> The one restriction is that in the case of the struct, you can’t have 
> initialized any of the immutable properties before assigning to self.
> 
> struct S {
>   let foo: String
>   
>   init(foo: String) {
>   self.foo = foo
>   }
>   
>   init(bar: String) {
>   self.foo = "Foo"
>   self = S(foo: bar) // error: immutable value 'self.foo' may 
> only be initialized once
>   }
> }
> 
> The only real thing being proposed here, as I see it, is to make this 
> behavior conceptually consistent with classes. Anything that simplifies the 
> rather Byzantine rules surrounding initializers, while simultaneously 
> enabling factory initializers, is a win in my book.
> 
> Charles
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 things to self can already be done with structs and enums:

struct S {
let foo: String

init(foo: String) {
self.foo = foo
}

init(bar: String) {
self = S(foo: bar) // works fine
}
}

enum E {
case foo
case bar

init(isFoo: Bool) {
if isFoo {
self = .foo // works fine
} else {
self = .bar // ditto
}
}
}

The one restriction is that in the case of the struct, you can’t have 
initialized any of the immutable properties before assigning to self.

struct S {
let foo: String

init(foo: String) {
self.foo = foo
}

init(bar: String) {
self.foo = "Foo"
self = S(foo: bar) // error: immutable value 'self.foo' may 
only be initialized once
}
}

The only real thing being proposed here, as I see it, is to make this behavior 
conceptually consistent with classes. Anything that simplifies the rather 
Byzantine rules surrounding initializers, while simultaneously enabling factory 
initializers, is a win in my book.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gor Gyolchanyan via swift-evolution]

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 
return`, which simply fails the initializer upon return, while allowing members 
to be left uninitialized (which is exactly what happens if you `return nil`).
The only way to avoid failing the initializer at this point is to directly 
assign to self.
Seems like in both of these scenarios there are not uninitialized members 
because either the initializer fails, of `self` is assigned a fully-formed 
instance.

About #3:

The idea behind `self.member = MemberType?(parameters)` is to first call the 
failable initializer of `MemberType` and in case it fails, immediately fail the 
enclosing failable initializer which the member is being initialized in. This 
guarantees that this member is either initialized, or the failable initializer 
returns nil immediately.

> On Jun 8, 2017, at 5:19 PM, David Sweeris  wrote:
> 
> 
>> 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. 
>> 
>> 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.
>> 
>> 2. Arbitrary `return` Statements In Intializers
>> 
>> The second idea is to allow `return ...` inside all initializers, which 
>> should also, theoretically, be a simple rewrite to `self = ...; return`. 
>> This one is to complement the existing `return nil` and allow some 
>> super-short initializers with a switch that returns in all cases or a more 
>> complex initializer that has a lot of guard statements.
>> 
>> 2.1. Future Factory Initializers
>> 
>> In addition, the `return ...` syntax has the benefit for potential factory 
>> initializers. So far, the proposals for factory initializers involved a 
>> keyword attached to the initializer, which just complicates the lexical 
>> structure of the language and adds unnecessary complication to the interface 
>> of types. Currently, factory initializers imported from Objective-C or from 
>> C using the `__attribute__((swift_name("MyType.init(self:...)")))` look like 
>> normal initializers (an in case of C, the return value doesn't even have to 
>> be related to the enclosing type in any way), but behave as you'd expect: 
>> you call the initializer and the result is a value that *should* be a 
>> subtype of the type you've called the initializer for. So, if in the future 
>> Swift gets native factory initializers (including, most importantly, in 
>> protocols), it won't require special syntax, because simply returning an 
>> instance of a subtype (with a compile-time check, of course) would look and 
>> behave very intuitively. This would also be very useful for singletons, 
>> which would use a private initializer for creating the instance and a public 
>> factory initializer for returning it.
>> 
>> 3. Failable Member Initialization
>> 
>> The third idea is to allow writing `self.member = MemberType?(...)` or 
>> `self.member = .init?(...)` (the exact syntax is up to debate) inside 
>> failable initializers, which would be simply rewritten as:
>> 
>> guard let _self_member = MemberType(...)  else {
>>   return nil
>> }
>> self.member = _self_member
>> 
>> This will dramatically reduce the boilerplate and visual clutter form 
>> complex failable initializers that call other failable initializers. A good 
>> use case would be complex `LosslessStringConvertible` types with many 
>> `LosslessStringConvertible` members.
>> 
>> So, what do you guys think?
> 
> #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.
> 
> - Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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. 
> 
> 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.
> 
> 2. Arbitrary `return` Statements In Intializers
> 
> The second idea is to allow `return ...` inside all initializers, which 
> should also, theoretically, be a simple rewrite to `self = ...; return`. This 
> one is to complement the existing `return nil` and allow some super-short 
> initializers with a switch that returns in all cases or a more complex 
> initializer that has a lot of guard statements.
> 
> 2.1. Future Factory Initializers
> 
> In addition, the `return ...` syntax has the benefit for potential factory 
> initializers. So far, the proposals for factory initializers involved a 
> keyword attached to the initializer, which just complicates the lexical 
> structure of the language and adds unnecessary complication to the interface 
> of types. Currently, factory initializers imported from Objective-C or from C 
> using the `__attribute__((swift_name("MyType.init(self:...)")))` look like 
> normal initializers (an in case of C, the return value doesn't even have to 
> be related to the enclosing type in any way), but behave as you'd expect: you 
> call the initializer and the result is a value that *should* be a subtype of 
> the type you've called the initializer for. So, if in the future Swift gets 
> native factory initializers (including, most importantly, in protocols), it 
> won't require special syntax, because simply returning an instance of a 
> subtype (with a compile-time check, of course) would look and behave very 
> intuitively. This would also be very useful for singletons, which would use a 
> private initializer for creating the instance and a public factory 
> initializer for returning it.
> 
> 3. Failable Member Initialization
> 
> The third idea is to allow writing `self.member = MemberType?(...)` or 
> `self.member = .init?(...)` (the exact syntax is up to debate) inside 
> failable initializers, which would be simply rewritten as:
> 
> guard let _self_member = MemberType(...)  else {
>return nil
> }
> self.member = _self_member
> 
> This will dramatically reduce the boilerplate and visual clutter form complex 
> failable initializers that call other failable initializers. A good use case 
> would be complex `LosslessStringConvertible` types with many 
> `LosslessStringConvertible` members.
> 
> So, what do you guys think?

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

- Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Uniform Initialization Syntax

[Gor Gyolchanyan via swift-evolution]

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

2. Arbitrary `return` Statements In Intializers

The second idea is to allow `return ...` inside all initializers, which should 
also, theoretically, be a simple rewrite to `self = ...; return`. This one is 
to complement the existing `return nil` and allow some super-short initializers 
with a switch that returns in all cases or a more complex initializer that has 
a lot of guard statements.

2.1. Future Factory Initializers

In addition, the `return ...` syntax has the benefit for potential factory 
initializers. So far, the proposals for factory initializers involved a keyword 
attached to the initializer, which just complicates the lexical structure of 
the language and adds unnecessary complication to the interface of types. 
Currently, factory initializers imported from Objective-C or from C using the 
`__attribute__((swift_name("MyType.init(self:...)")))` look like normal 
initializers (an in case of C, the return value doesn't even have to be related 
to the enclosing type in any way), but behave as you'd expect: you call the 
initializer and the result is a value that *should* be a subtype of the type 
you've called the initializer for. So, if in the future Swift gets native 
factory initializers (including, most importantly, in protocols), it won't 
require special syntax, because simply returning an instance of a subtype (with 
a compile-time check, of course) would look and behave very intuitively. This 
would also be very useful for singletons, which would use a private initializer 
for creating the instance and a public factory initializer for returning it.

3. Failable Member Initialization

The third idea is to allow writing `self.member = MemberType?(...)` or 
`self.member = .init?(...)` (the exact syntax is up to debate) inside failable 
initializers, which would be simply rewritten as:

guard let _self_member = MemberType(...)  else {
return nil
}
self.member = _self_member

This will dramatically reduce the boilerplate and visual clutter form complex 
failable initializers that call other failable initializers. A good use case 
would be complex `LosslessStringConvertible` types with many 
`LosslessStringConvertible` members.

So, what do you guys think?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution