Re: [swift-evolution] Swift phases and mis-timed proposals

[Ted Kremenek via swift-evolution]

Everyone: this is a great thread, and I appreciate the candid thoughts here.  
This is something Ben Cohen and I started chatting about offline and we’ll 
definitely bring it up for discussion with the rest of the Core Team.

I realize there is a tension here, and a sense of frustration, because ideas 
sometimes feel like they don’t get air time or it isn’t clear what’s the right 
conduit for discussing them.  I’m still mulling over the thoughts on this 
thread, but I’d first like to respond to Xiaodi’s point below.

> On Jun 11, 2017, at 2:54 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> A key question here to be answered is: is this mailing list the appropriate 
> forum for "discussing ideas right away," whatever they might be? or is it 
> more of a working list for bringing forward in-scope proposals in the 
> successive forms of pitch, draft, and proposal review? As far as I can tell, 
> the aim of scoping rules is to nudge it towards the latter, and personally I 
> think that's quite nice in terms of bringing sanity back to my inbox as well 
> as focus to the discussions. By contrast, I have seen blogs, Twitter, and 
> other channels used profitably for discussing ideas right away, and 
> personally I've found off-list communications to be the best way to prepare 
> for the much more difficult task of convincing the discerning crowd here.

I think this captures the current reality fairly well.  In the Swift 3 
timeframe, the swift-evolution process/venue was brand new and lots of 
discussion emerged on the swift-evolution list almost overnight.  Further, 
while there was a scope of the changes in Swift 3 they were pretty vast and 
encompassing.  For myself and other members of the Core Team the evolution 
discussion at times also felt a bit overwhelming.  Beyond the investment in 
shaping the swift-evolution community, it was a struggle to balance 
discussions, design work, and implementation work that aligned with Swift 3.

The phases of discussion we see in Swift 4 in many ways are a direct response 
to trying to instill a bit more order to make swift-evolution both less chaotic 
but also fit with the rhythm of the release.  Swift release follow a fairly 
predictable schedule, roughly following Apple’s yearly OS release cadence with 
the first “beta” of the major release of the language in June (aligning with 
WWDC).  The engineering and design work for a Swift release pretty much orients 
around that.  My hope is that major design discussions that define a release 
come earlier in the release cycle, with proposals trickling in as refinements.  
We saw that a bit in Swift 4 with the String Manifesto and the Ownership 
Manifesto.  We also phrased “phase 1” as being very focused so that critical 
momentum on Swift 4 could be established without discussions unrelated to the 
release creating major distractions for the community and the Core Team.  With 
“phase 2” the scope of what was on topic for Swift 4 was opened up a bit, but 
even that was hit and miss. We took some proposals very late that also landed 
with hot implementations.  As it is, some proposals simply were beyond our 
capacity to implement, such as SE-0155.  The fate of SE-0155 in particular will 
need to be re-evaluated once we look at the scope for Swift 5 (TBD).

Getting to Xiaodi’s observation, the evolution list is really the most 
effective as a working list for bringing forward in-scope proposals.  There’s a 
ton of different topics people want to talk about — and their is some obvious 
angst about getting to those — but at the end of the day there is only so much 
bandwidth from everyone to pay attention to these discussions and to get 
seriously invested in them.  Maybe moving to Discourse (which is something we 
still want to do, but have had limited bandwidth to implement) will provide the 
“off-list” communication channels analogous to the ones Xiaodi describes that 
keeps those discussions in the Swift.org discussion forums but clearly 
separates discussion for in-scope proposals versus the side discussions people 
want to have on topics they are interested in.  Even in this setup, however, I 
think everyone needs to acknowledge that members of the Core Team or anyone 
else active in the evolution process has limited capacity to participate in 
only so many discussions.  In reality, the discussions that are about in-scope 
proposals will continue to get the priority attention even if there is a place 
to discuss things that are out-of-scope.

I appreciate everyone’s thoughts here, and myself and other members of the Core 
Team are keenly interested in finding ways to improve the nature of 
swift-evolution for the benefits of its participants and the broader Swift 
community.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift phases and mis-timed proposals

[Gor Gyolchanyan via swift-evolution]

I have to constantly suppress all ideas (big or small) because I don't want to 
flood the mailing list with spam.
In the case of factory initializers, it seemed like something a lot of people 
yearn for (myself included), so pushing for it in the wake of Swift 4 seemed 
like an appropriate time.
But otherwise, It would be nice to get a more volatile mailing list 
specifically for out-of-place (and potentially huge, game-changing) ideas.
We would then collectively compose a monthly or quarterly (or whatever) summary 
of what has been going on in the volatile mailing list for the people with more 
timely priorities to be able to keep track of (including the core team).

> On Jun 12, 2017, at 2:47 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 11, 2017, at 3:41 PM, Haravikk via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution 
>>> > wrote:
>>> 
>>> I agree, this makes focusing on the right types of changes much easier and 
>>> helps us avoid turning Swift into an incoherent conglomeration of random 
>>> use-cases (*cough*, C#, *cough*).
>>> Now, the question is: when will be the time to officially push the factory 
>>> initializers proposal and which stage should it be targeting?
>> 
>> I think there's definitely a need for greater clarity; we could really do 
>> with better announcements on the list itself as to when the new phase begins 
>> and exactly what is in-scope, it also needs to be put more clearly on the 
>> swift-evolution repository.
>> 
>> Thing is; people are going to have ideas when they have them, and want to 
>> discuss them right away. I've been caught out numerous times with proposals 
>> that are almost immediately rejected as out of scope, and still have no idea 
>> when I'm supposed to resubmit them.
>> 
>> To be honest it's demoralising, as I find myself apathetic towards my own 
>> ideas as I have no idea when to revisit them, and by the time I do I've 
>> largely lost interest and moved on to other things.
>> ___
> 
> This.
> 
> I am sitting on a number of ideas that I think have merit (in a non-random 
> use-case non-C# way) and I have no idea when the right time will be to bring 
> them up. Several were marked as "bring forward to Swift 4" and obvious that 
> was never going to happen for them.
> 
> I think having a queue to submit "proposals for eventually", written when the 
> inspiration is there, and having a core team review (say once a month or even 
> once a quarter) of their viability for future Swift directions would be 
> amazingly valuable.
> 
> An example: https://github.com/apple/swift-evolution/pull/369 
> 
> 
> -- E
> 
> ___
> 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]

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] Int indexing into UTF16View

[David Hart via swift-evolution]

> On 11 Jun 2017, at 02:49, Ben Cohen  wrote:
> 
> 
>> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Hello,
>> 
>> When working with Strings which are known to be ASCII, I tend to use the 
>> UTF16View for the performance of random access. I would also like to have 
>> the convenience of indexing with Int:
>> 
>> let barcode = "M1X/CLEMENT   EELT9QBQGVAAMSEZY1353 244 21D 531  
>> 10A1311446838”
>> let name = barcode.utf16[2..<22]
>> let pnrCode = barcode.utf16[23..<30]
>> let seatNo = barcode.utf16[47..<51]
>> let fromCity = barcode.utf16[30..<33]
>> let toCity = barcode.utf16[33..<36]
>> let carrier = barcode.utf16[36..<39]
>> let flightNumber = barcode.utf16[39..<44]
>> let day = barcode.utf16[44..<47]
>> 
>> I define my own subscript in an extension to UTF16View but I think this 
>> should go in the Standard Library.
>> Any thoughts?
>> 
>> David.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> Hi David,
> 
> My view is positional shredding of strings is enough of a use case that we 
> ought to think about handling it better. I don’t think having to convert the 
> string into an Array of Character, or bytes, or use Data, should be 
> necessary, since this implies losing the stringiness of the slices you are 
> creating, which is an inconvenience for many use cases. Strings-as-data is a 
> thing we should support, and support well.
> 
> But I also don’t think giving String or its views integer indices is the 
> right way to go either, incorrectly implying as it does random access 
> 
> (or, even if we did end up making utf16 permanently random-access, 
> encouraging people towards using utf16 to support this use case when often 
> they’d be better served sticking with characters).
> 
> There’s a few things to note about the example you give:
> 1) Do you really want utf16 view slices for your variable types? Maybe in 
> this case you do, but I would guess a lot of the time what is desired would 
> be a (sub)string.

Not really. I would be quite happy with Substring. The variable type is just 
the consequence of my choice of the UTF16 view.

> 2) Do you really want to hard-code integer literals into your code? Maybe for 
> a quick shell script use case, but for anything more this seems like an 
> anti-pattern that integer indices encourage.

I agree. I took the code out of a project of mine and simplified it. I have the 
Int ranges defined as named constants.

> 3) Are you likely to actually want validation at each step – that the string 
> was long enough, that the string data was valid at that point?

No. I pre-validate the string and it's length beforehand.

> 4) This case doesn’t seem to need random access particularly, so much as the 
> (questionable? see above) convenience of integer indexing. Although reordered 
> in the example, it seems like the code could be written to progressively 
> traverse the string from left to right to get the fields. Unless the plan is 
> to repeatedly access some fields over and over. But I’m not sure we’d want to 
> put affordances into the std lib to encourage accessing stringly typed data...

Indeed. I initially rewrote the code to traverse the string from left to write, 
advancing indices by deltas. But (1) it made the code less readable, (2) 
further removed from the barcode spec which is defined in terms of offsets, and 
(3) more brittle - editing deltas forces chain modifications:

let nameStart = barcode.index(name.startIndex, offsetBy: 2)
let nameEnd = barcode.index(nameStart, offsetBy: 20)
let name = barcode[nameStart.. So the question is, what affordances should we put into the standard library, 
> or maybe other libraries, to help with these use cases? This is a big design 
> space to explore, and at least some ideas ought to feed into our ongoing 
> improvements to String for future releases.
> 
> For example:
> 
> Now that we have Substring, it opens up the ability to efficiently consume 
> from the front (since it’s just adjusting the substring range):
> 
> extension Collection where Self == SubSequence {
> // or some better name...
> mutating func removeFirst(_ n: IndexDistance) -> SubSequence? {
> guard let i = index(startIndex, offsetBy: n, limitedBy: endIndex)
> else { return nil }
> 
> defer { self = self[i...] }
> return self[.. }
> }
> 
> Once you have this, you could use it to write the example code, along with 
> some error checking (or you could use ! if you were completely certain of the 
> integrity of your data)
> 
> var s = barcode[...] // make a substring for efficient consumption
> _ = 

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

[T.J. Usiyan via swift-evolution]

+1

I only gave it a quick read though.

On Sun, Jun 11, 2017 at 3:01 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> Overall, I am strong +1 on this, but I don’t have time to go through a
> detailed analysis of how it will affect my own use cases.
>
> On Jun 4, 2017, at 4:29 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of SE-0180 "String Index Overhaul" begins now and runs through 
> *June
> 8, 2017*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0180-string-index-overhaul.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0180-string-index-overhaul.md
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
> Ted (Review Manager)
> ___
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift phases and mis-timed proposals

[Erica Sadun via swift-evolution]

> On Jun 11, 2017, at 3:41 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution 
>> > wrote:
>> 
>> I agree, this makes focusing on the right types of changes much easier and 
>> helps us avoid turning Swift into an incoherent conglomeration of random 
>> use-cases (*cough*, C#, *cough*).
>> Now, the question is: when will be the time to officially push the factory 
>> initializers proposal and which stage should it be targeting?
> 
> I think there's definitely a need for greater clarity; we could really do 
> with better announcements on the list itself as to when the new phase begins 
> and exactly what is in-scope, it also needs to be put more clearly on the 
> swift-evolution repository.
> 
> Thing is; people are going to have ideas when they have them, and want to 
> discuss them right away. I've been caught out numerous times with proposals 
> that are almost immediately rejected as out of scope, and still have no idea 
> when I'm supposed to resubmit them.
> 
> To be honest it's demoralising, as I find myself apathetic towards my own 
> ideas as I have no idea when to revisit them, and by the time I do I've 
> largely lost interest and moved on to other things.
> ___

This.

I am sitting on a number of ideas that I think have merit (in a non-random 
use-case non-C# way) and I have no idea when the right time will be to bring 
them up. Several were marked as "bring forward to Swift 4" and obvious that was 
never going to happen for them.

I think having a queue to submit "proposals for eventually", written when the 
inspiration is there, and having a core team review (say once a month or even 
once a quarter) of their viability for future Swift directions would be 
amazingly valuable.

An example: https://github.com/apple/swift-evolution/pull/369 


-- E

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

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

[Dave Abrahams via swift-evolution]

on Fri Jun 09 2017, Matthew Johnson  wrote:

>> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution
>>  wrote:
>> 
>> On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution
>> 
>> >
>> wrote:
>> Somewhat related to this, shouldn’t it be possible to sub-struct a
>> struct as long as you only add functions and computed properties
>> (i.e., no stored properties)? Traditionally structs cannot be
>> subtyped because their size must be known at compile time. I don’t
>> know the implementation details of where functions and computed
>> properties live, but something tells me they belong to the type and
>> not the object (although I’ve never really made the effort to sit
>> down and fully understand Swift’s type model), in which case adding
>> them to a struct’s definition would not change the size of the
>> object on the stack. Thus it should be possible to make custom
>> substructs of String that add additional functionality but no new
>> stored properties. Thoughts?
>> 
>> Value subtyping is a large subject and, IIUC, newtype would be a
>> subset of that topic. Unlikely to be in scope for Swift 5, though,
>> but that’s up to the core team.
>
> I see newtype as being more related to forwarding than subtyping.
> Usually you want to hide significant parts of the interface to the
> wrapped type.

Yes, and whether you want an implicit conversion relationship between
the newtype and the old is an orthogonal issue.

-- 
-Dave

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 11, 2017, at 14:41, Haravikk via swift-evolution 
>  wrote:
> 
> Thing is; people are going to have ideas when they have them, and want to 
> discuss them right away. I've been caught out numerous times with proposals 
> that are almost immediately rejected as out of scope, and still have no idea 
> when I'm supposed to resubmit them.
> 
> To be honest it's demoralising, as I find myself apathetic towards my own 
> ideas as I have no idea when to revisit them, and by the time I do I've 
> largely lost interest and moved on to other things.

Yeah, I hope we'll get an "out of scope" section when we move to discourse... 
That way the core team and others who are busy can focus on what's practical 
for the next release, and those of us who have ideas that are a bit premature 
will have a place to discuss and refine them (and one where we don't have to 
spend an hour or so combing through our social media history just to find it).

Either way, though, I think restricting ourselves to a set of "in-scope" topics 
is likely about the only way we'll be able to collectively stay focused enough 
to get anything done.

- Dave Sweeris 

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[Xiaodi Wu via swift-evolution]

On Sun, Jun 11, 2017 at 4:41 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree, this makes focusing on the right types of changes much easier and
> helps us avoid turning Swift into an incoherent conglomeration of random
> use-cases (*cough*, C#, *cough*).
> Now, the question is: when will be the time to officially push the factory
> initializers proposal and which stage should it be targeting?
>
>
> I think there's definitely a need for greater clarity; we could really do
> with better announcements on the list itself as to when the new phase
> begins and *exactly* what is in-scope, it also needs to be put more
> clearly on the swift-evolution repository.
>
> Thing is; people are going to have ideas when they have them, and want to
> discuss them right away. I've been caught out numerous times with proposals
> that are almost immediately rejected as out of scope, and still have no
> idea when I'm supposed to resubmit them.
>
> To be honest it's demoralising, as I find myself apathetic towards my own
> ideas as I have no idea when to revisit them, and by the time I do I've
> largely lost interest and moved on to other things.
>

I think many of us who've tried our hand at getting proposals through the
process have experienced the setback of a potential worthwhile idea not
receiving an audience. Yet, on balance, I still think the process handles
out-of-scope ideas appropriately.

A key question here to be answered is: is this mailing list the appropriate
forum for "discussing ideas right away," whatever they might be? or is it
more of a working list for bringing forward in-scope proposals in the
successive forms of pitch, draft, and proposal review? As far as I can
tell, the aim of scoping rules is to nudge it towards the latter, and
personally I think that's quite nice in terms of bringing sanity back to my
inbox as well as focus to the discussions. By contrast, I have seen blogs,
Twitter, and other channels used profitably for discussing ideas right
away, and personally I've found off-list communications to be the best way
to prepare for the much more difficult task of convincing the discerning
crowd here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift phases and mis-timed proposals

[Haravikk via swift-evolution]

> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I agree, this makes focusing on the right types of changes much easier and 
> helps us avoid turning Swift into an incoherent conglomeration of random 
> use-cases (*cough*, C#, *cough*).
> Now, the question is: when will be the time to officially push the factory 
> initializers proposal and which stage should it be targeting?

I think there's definitely a need for greater clarity; we could really do with 
better announcements on the list itself as to when the new phase begins and 
exactly what is in-scope, it also needs to be put more clearly on the 
swift-evolution repository.

Thing is; people are going to have ideas when they have them, and want to 
discuss them right away. I've been caught out numerous times with proposals 
that are almost immediately rejected as out of scope, and still have no idea 
when I'm supposed to resubmit them.

To be honest it's demoralising, as I find myself apathetic towards my own ideas 
as I have no idea when to revisit them, and by the time I do I've largely lost 
interest and moved on to other things.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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] Swift phases and mis-timed proposals

[Gor Gyolchanyan via swift-evolution]

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[Gor Gyolchanyan via swift-evolution]

I agree, this makes focusing on the right types of changes much easier and 
helps us avoid turning Swift into an incoherent conglomeration of random 
use-cases (*cough*, C#, *cough*).
Now, the question is: when will be the time to officially push the factory 
initializers proposal and which stage should it be targeting?

> On Jun 12, 2017, at 12:06 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I think there is merit to the current system, although it can be annoying.
> 
> I’m sure we can all agree that a properly submitted and approved proposal 
> should have solicited the fullest possible feedback at each stage, including 
> the initial pitch stages. Based on the experience of Swift 3 evolution, 
> however, it’s clear that there is limited bandwidth for participants to 
> engage fully with all possible topics.
> 
> The innovation of defining priorities for each phase has really helped to 
> bring about a more manageable process for everyone, I think. If a proposal is 
> not in scope, then participants don’t (and shouldn’t) feel like they miss an 
> opportunity to help shape a feature by sitting out the conversation. 
> Therefore, by definition, any such out-of-scope conversations will not get 
> the fullest possible feedback from community when it is pitched, and it 
> should go through the pitch process again from the beginning if the aim is to 
> progress to the next stage.
> 
> Otherwise, you’re basically exempting the initial pitch stage from the 
> parameters of what’s out of scope, defeating the purpose of that innovation.
> 
> On Sun, Jun 11, 2017 at 15:48 Daryle Walker via swift-evolution 
> > wrote:
> I’ve read about the Swift developers taking certain kinds of proposals during 
> certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if 
> someone writes a proposal that isn’t of the type of the current phase, it’s 
> auto-rejected. Is it possible to set some kind of proposal queue so their 
> authors don’t have to guess when it’s the right time to resubmit?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> 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

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[Xiaodi Wu via swift-evolution]

I think there is merit to the current system, although it can be annoying.

I’m sure we can all agree that a properly submitted and approved proposal
should have solicited the fullest possible feedback at each stage,
including the initial pitch stages. Based on the experience of Swift 3
evolution, however, it’s clear that there is limited bandwidth for
participants to engage fully with all possible topics.

The innovation of defining priorities for each phase has really helped to
bring about a more manageable process for everyone, I think. If a proposal
is not in scope, then participants don’t (and shouldn’t) feel like they
miss an opportunity to help shape a feature by sitting out the
conversation. Therefore, by definition, any such out-of-scope conversations
will not get the fullest possible feedback from community when it is
pitched, and it should go through the pitch process again from the
beginning if the aim is to progress to the next stage.

Otherwise, you’re basically exempting the initial pitch stage from the
parameters of what’s out of scope, defeating the purpose of that innovation.

On Sun, Jun 11, 2017 at 15:48 Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve read about the Swift developers taking certain kinds of proposals
> during certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So
> if someone writes a proposal that isn’t of the type of the current phase,
> it’s auto-rejected. Is it possible to set some kind of proposal queue so
> their authors don’t have to guess when it’s the right time to resubmit?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> ___
> 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

[swift-evolution] Swift phases and mis-timed proposals

[Daryle Walker via swift-evolution]

I’ve read about the Swift developers taking certain kinds of proposals during 
certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if someone 
writes a proposal that isn’t of the type of the current phase, it’s 
auto-rejected. Is it possible to set some kind of proposal queue so their 
authors don’t have to guess when it’s the right time to resubmit?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

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] [Review] SE-0180: String Index Overhaul

[Hooman Mehr via swift-evolution]

Overall, I am strong +1 on this, but I don’t have time to go through a detailed 
analysis of how it will affect my own use cases. 

> On Jun 4, 2017, at 4:29 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0180 "String Index Overhaul" begins now and runs through 
> June 8, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
>  
> 
> Reply text
> 
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> Ted (Review Manager)
> 
> ___
> 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]

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] [Pitch] #error

[Beta via swift-evolution]

A proposal and implementation of #warning exist.  It has been judged out of 
scope for Swift 3 and Swift 4 phase 2. 

https://github.com/apple/swift-evolution/pull/353 
 

> On Jun 10, 2017, at 10:15 AM, Daryle Walker via swift-evolution 
>  wrote:
> 
> Unconditional Error Messages
> Proposal: SE- 
> Authors: Daryle Walker , Author 2 
> 
> Review Manager: TBD
> Status: Awaiting review
> During the review process, add the following fields as needed:
> 
> Decision Notes: Rationale 
> , Additional Commentary 
> 
> Bugs: SR- , SR- 
> 
> Previous Revision: 1 
> 
> Previous Proposal: SE- 
> Introduction
> This proposal adds the #error directive, which unconditionally posts a 
> compile-time error.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
> Motivation
> A conditional compilation block permits branches of code based on the 
> compilation conditions.
> 
> #if compilation condition 1
> // statements to compile if compilation condition 1 is true
> #elseif compilation condition 2
> // statements to compile if compilation condition 2 is true
> #else
> // statements to compile if both compilation conditions are false
> #endif
> A block lets at most one of its branches to be incorporated into the compiled 
> module. But compilation always occurs; there is no scenario to flag 
> conditions that should never allow compiling.
> 
> When suspending work on a source file for a while, marking where you ended 
> work with an unconditional error message would let the compiler remind you 
> where you left off.
> 
> Proposed solution
> The solution is to add a new compiler control statement, one that posts a 
> fatal diagnostic during compilation. It can include a message to aid the user 
> on how to change their code.
> 
> It's called #error, after the C preprocessor directive that has the same 
> effects.
> 
> For example, instead of checking API compatibility at run-time:
> 
> guard #available(tvOS 1.0, *) else {
> fatalError("We need a TV.")
> }
> 
> // Do what we're supposed to do
> We can move the check to compile-time:
> 
> #if os(tvOS)
> // Do what we're supposed to do
> #else
> #error("We need a TV.")
> #endif
> Detailed design
> Add to the "Grammar of a Compiler Control Statement":
> 
> compiler-control-statement → error-directive-statement­
> Add a new section "Grammar of a Error Directive Statement":
> 
> error-directive-statement → #error ( static-string-literal )
> The semantics of an error directive statement are: when such a statement is 
> encountered during translation, and it is not in an inactive compilation 
> block branch, compilation is aborted and the directive's string is included 
> in the diagnostic of the directive's source line.
> 
> Source compatibility
> This proposal should cause no problems with source compatibility. Relative to 
> the current grammar, there is an addition of one token: #error. Since 
> #-leading tokens are illegal except for the explicitly defined ones, there is 
> no possibly of token overlap in legacy code.
> 
> Effect on ABI stability
> Since the domain of this proposal is all in the compilation phase of creating 
> object code, there is no effect on ABI stability.
> 
> Effect on API resilience
> The domain of this proposal, controlling whether translation completes, does 
> not affect any API.
> 
> Alternatives considered
> The alternative is to do nothing. This would mean any checks would stay being 
> delayed into run-time, and calling fatalError or similar functions to avoid 
> implementing uncovered compilation cases.
> 
> The original C syntax left open tokens as the message after the #error token. 
> I decided to enclose the message as a string to ease parsing.
> 
> Future directions
> The original idea for this proposal was a distraction while bringing an 
> adaptation of C++'s static_assert, as defined in its proposal 
> . The 
> static_assert is a condition-checking mechanic between assert and #error; 
> Swift already has the former and this proposal would bring the latter. 
> There'd still be no equivalent for static_assert. Another proposal for 
> non-environment compile-time expressions and their use in generic where 
> clauses would relieve most of need for static_assert, but there needs to be 
> either a new construct a declaration-level version or #if/#elseif need to be 
> allowed to access non-environment compile-time expressions.
> 
> Acknowledgements
> How to Use the C 

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] [Pitch] #error

[Gor Gyolchanyan via swift-evolution]

I was playing around with Swift's mysterious Builtin module, accessible via the 
`-parse-stdlib` compiler flag and I noticed a builtin primitive that causes a 
fatal error if the branch it's in is not optimized away. This seems like an 
opportunity for a much more powerful "this place is not implemented", where the 
execution branch analyzer can determine at compile time for specific cases 
whether or not the unimplemented branch will be accessed. We could make a 
proposal to introduce a new compiler directive of the following form:

public func #unavailable(_ message: String? = nil) -> Never

This directive would be allowed both in function scope and global scope.
Calls to this directive would generate a compile-time error when the execution 
path it's located in can be guaranteed and a run-time error in all other cases.
Placing this directive in the global scope would generate a compile-time error 
unconditionally.

The only way to avoid this error is to either have the call to it optimized 
away or conditionally compiled out:

#if os(macOS)
import Cocoa
#else
#unavailalbe("Sorry, pal. I only work with macs.")
#endif

func compare(_ x: Int, _ y: Int) -> Int {
if x > 0 {
return 1
} else if x == 0 {
return 0
} else if x < 0 {
return -1
} else {
#unavailable("How the hell did you managed to get here?")
}
}

> On Jun 11, 2017, at 7:45 PM, Javier Soto via swift-evolution 
>  wrote:
> 
> +1 on adding a compile-time error directive. #error seems like the right 
> syntax as well.
> I had a maybe nit-picky comment about the proposal though. I think the 
> example may not be ideal, since you could accomplish that compile-time error 
> by annotating the method or class where that code lives with @available(tvOS) 
> , no?
> On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution 
> > wrote:
> This is the best I've found for searching the archives: 
> https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22
>  
> 
> 
> 
> 
> On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution 
> > wrote:
> 
> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  > > wrote:
> >
> > Daryle, there have been several pitches in the past with respect to #error, 
> > and very enlightening arguments both for and against the idea have been 
> > eloquently written.
> >
> > Since you’re resurrecting this idea, could I suggest going back through the 
> > archives and linking to and summarizing these arguments, so that we’re not 
> > restarting the discussion from scratch? :)
> 
> Is there somewhere to search the archives?
> 
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
> 
> ___
> 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 
> 
> -- 
> Javier Soto
> ___
> 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

[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] [Pitch] #error

[Javier Soto via swift-evolution]

+1 on adding a compile-time error directive. #error seems like the right
syntax as well.
I had a maybe nit-picky comment about the proposal though. I think the
example may not be ideal, since you could accomplish that compile-time
error by annotating the method or class where that code lives with
@available(tvOS) , no?
On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution <
swift-evolution@swift.org> wrote:

> This is the best I've found for searching the archives:
> https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22
>
>
>
> On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
>> >
>> > Daryle, there have been several pitches in the past with respect to
>> #error, and very enlightening arguments both for and against the idea have
>> been eloquently written.
>> >
>> > Since you’re resurrecting this idea, could I suggest going back through
>> the archives and linking to and summarizing these arguments, so that we’re
>> not restarting the discussion from scratch? :)
>>
>> Is there somewhere to search the archives?
>>
>> —
>> Daryle Walker
>> Mac, Internet, and Video Game Junkie
>> darylew AT mac DOT com
>>
>> ___
>> 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
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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] [Pitch] #error

[Will Field-Thompson via swift-evolution]

This is the best I've found for searching the archives:
https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22



On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
> >
> > Daryle, there have been several pitches in the past with respect to
> #error, and very enlightening arguments both for and against the idea have
> been eloquently written.
> >
> > Since you’re resurrecting this idea, could I suggest going back through
> the archives and linking to and summarizing these arguments, so that we’re
> not restarting the discussion from scratch? :)
>
> Is there somewhere to search the archives?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> ___
> 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

[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] [Pitch] #error

[Xiaodi Wu via swift-evolution]

Nate Cook staged a Discourse server that is searchable for a portion of the
archives. A quick Google search will get you there, although at the moment
lists.swift.org doesn’t seem to be responding, so I can’t send you the link
off-hand.

For threads outside the range of that resource, I‘d recommend searching
whatever email archives you have locally, but generally I find that to be
hit-and-miss myself. To get the rest of the way, in the past I’ve manually
combed through all of the weekly archives on lists.swift.org; it’s not fun
but it’s doable.


On Sun, Jun 11, 2017 at 05:30 Daryle Walker  wrote:

>
> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
> >
> > Daryle, there have been several pitches in the past with respect to
> #error, and very enlightening arguments both for and against the idea have
> been eloquently written.
> >
> > Since you’re resurrecting this idea, could I suggest going back through
> the archives and linking to and summarizing these arguments, so that we’re
> not restarting the discussion from scratch? :)
>
> Is there somewhere to search the archives?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
>
___
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]

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] [Pitch] #error

[Daryle Walker via swift-evolution]

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
> 
> Daryle, there have been several pitches in the past with respect to #error, 
> and very enlightening arguments both for and against the idea have been 
> eloquently written.
> 
> Since you’re resurrecting this idea, could I suggest going back through the 
> archives and linking to and summarizing these arguments, so that we’re not 
> restarting the discussion from scratch? :)

Is there somewhere to search the archives?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

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