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

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

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

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.

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

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

Re: [swift-evolution] Int indexing into UTF16View

> 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

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

+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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

* 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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

Re: [swift-evolution] [Pitch] #error

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 >

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

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

Re: [swift-evolution] [Pitch] #error

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

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

On Sun, Jun 11, 2017 at 12:43 PM, Gor Gyolchanyan wrote: > I have no better name besides a factory initializer for now. > I have thought about this some more and came to this conclusion about the > keyword: > Let the keyword be universally applied to all factory

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

I have no better name besides a factory initializer for now. I have thought about this some more and came to this conclusion about the keyword: Let the keyword be universally applied to all factory initializers, to statically enforce the rules of factory initializers (see below), because the

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

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

Re: [swift-evolution] [Pitch] #error

+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

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

On Sun, Jun 11, 2017 at 10:34 AM, Gor Gyolchanyan wrote: > I just didn't want to use the commonly proposed `factory` word, because it > implies a specific semantic tied to the factory method pattern. > I gave it another thought and I'm thinking maybe we can forego the >

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

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

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

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

Re: [swift-evolution] [Pitch] #error

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,

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

On Sun, Jun 11, 2017 at 8:49 AM, Gor Gyolchanyan wrote: > Can you recall the reasons why the removal of access modifiers on > extensions was rejected? > It was an unassailable reason, really: people found this shorthand useful and wanted to continue to use it--it is the

Re: [swift-evolution] [Pitch] #error

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

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

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

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

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

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

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

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

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

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

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

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

Removal of access modifiers on extensions has been proposed, reviewed, and rejected, so that’s that. In general, Swift uses distinct keywords for distinct concepts, unlike Rust which likes to reuse keywords in clever ways; if you’re finding that things are getting confusing with one word meaning

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

I just didn't want to use the commonly proposed `factory` word, because it implies a specific semantic tied to the factory method pattern. I gave it another thought and I'm thinking maybe we can forego the annotation and have the compiler deduce it automatically. There are only two places where

Re: [swift-evolution] [Pitch] #error

> 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

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

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

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

Yeah, well I messed up my proposal from last year about removing the access modifier on extensions and wish now I wasn’t that confused back than and made it right. The indirect keyword is literally the same story. The docs only says that this is only a shortcut. „To enable indirection for all

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

I always wondered, why is `indirect` allowed on the `enum` itself? Wouldn't it make more sense to apply it to individual cases that recursively refer to the `enum`? This question also applies to access modifiers on extensions. So, what is it supposed to do? Change the default access modifier

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

The proposal is looking good to me. :) It will also enable easy support for custom views using XIBs in iOS development without unnecessary view nesting. For instance the function from this example https://stackoverflow.com/a/43123783/4572536 could be used directly inside an init: class MyView