[swift-evolution] Will existentials ever conform to their protocols?

Hello Swift Community! I know that I’ve seen this mentioned before, but what with Enhanced Existentials being brought up, I think this is worth mentioning now. What is the plan regarding letting existentials conform to their protocols? Currently, in Swift 3, it is impossible to write code

Re: [swift-evolution] Enhanced Existentials

Looking at that proposal on Austin’s Github, would its complete implementation require/allow for any type that’s known at runtime to be used like a type at compile time? So that these two blocks would both work? It seems like the runtime would be using the same technology, but it’s hard to

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

> > Of course, I would love being able to use an initializer setup, but there are > serious bugs in the implementation. > > protocol Clonable > { > init(other: Self) > } > > extension Clonable > { > func clone() -> Self > { return type(of: self).init(other: self) } >

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

> > One could workaround the problem and use final, but what if the class > meant to be subtypeable? Self simply does not work in this scenario. > > > It works exactly as it should in this scenario. If A isn't final, then by > definition it's impossible for A to make a copy of type Self. I

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I forgot to reply to the email list here. > On Dec 26, 2016, at 10:03 PM, Xiaodi Wu > wrote: > > Did you mean to reply offlist? > > Basically, a factory would be: > > func make(_: T.Type) -> T { return T() } > > but you need T to conform to

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I’m gonna do my best to explain my thoughts on this, as I just spent an hour reading the whole thread I’m -1 on adding the protocol DefaultConstructible to the standard library (especially under that name). It doesn’t explain its semantics effectively. I agree that a protocol should have

Re: [swift-evolution] Generic types―covariance/contravariance

I did some experimenting, and I see that most variance situations are covered by the compiler. Generic collections and wrappers, like Optional or Array, are acceptable with .map and .flatMap, but currently benefit from compiler magic to cast those types. However, not all the standard library

[swift-evolution] Generic types—covariance/contravariance

Has the core team or the community considered the possibility of implementing covariant/contravariant generic types? It would really be appreciated. I know with Array, vague-ifying or specific-ifying the type ([Int] to [Any]) has help from the compiler—and we can use `map` if all else

Re: [swift-evolution] [Idea] Extending syntax for `extension`

>> extension. >> >> Should nesting of extensions inside types be permitted, it would necessitate >> changes to access modifier rules that did not gain consensus for review in >> the Swift 3 timeline. >> >> On Mon, Dec 5, 2016 at 23:34 Braeden Profile via swift-

Re: [swift-evolution] [Idea] Extending syntax for `extension`

scope it’s defined in? > > Saagar Jha > > > >> On Dec 5, 2016, at 1:48 PM, Braeden Profile via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I really enjoy having the ability to write an

[swift-evolution] [Idea] Extending syntax for `extension`

I really enjoy having the ability to write and nesting my code at the appropriate indentation level in my file. Extensions are fabulous, but I wonder—solely for readability/style sake, could we allow you to properly namespace your extensions? Though I don’t know the implementation cost of

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

But what would that mean? If I reference `ProtocolName.InnerType`, that doesn’t always have meaning. In fact, if you have two different extensions where AssociatedType equals something else, there’s a type ambiguity from other code. I suspect it would only work if that InnerType was mandated

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

Awesome; +1. Does this address the lack of .init(keys:values:)? Would it make that addition easier? > On Oct 11, 2016, at 3:38 PM, Xiaodi Wu via swift-evolution > wrote: > > Very elegant solution. Strong +1; no other feedback comes to mind atm. > > > On Tue, Oct

Re: [swift-evolution] [Proposal] Enums with stored properties

So, just to recap, the proposed solution is to help enums expose associated values via properties, and is not to create enums that are open to extra unnamed cases (RectSize(width:0,height:10))? What I see is that enums would still maintain their standing where an instance is just a selection

Re: [swift-evolution] [proposal] Allow convenience initializers to use "self = Foo()"

Not good. In classes, we can’t always determine the exact type of "self”. In subclasses of “Me”, such an assignment would not work. Something like `self = Self(bar: foo)` could work, but that exact case is exactly the same as `self.init(bar: foo)`. I would still appreciate being able to do

Re: [swift-evolution] private & fileprivate

> > On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution > wrote: > > I was thinking that the domains themselves could be associated with a domain, > so you could create alternate domains which are also publicly-visible, but > distinct from the default, “public”

Re: [swift-evolution] private & fileprivate

> > On Oct 7, 2016, at 5:46 PM, Trans via swift-evolution > wrote: > > Private access that limits exposure to extensions and subclasses is > the bane of reusability. It sucks in Java and it sucks in Swift. As > far as I know Ruby is the only language that seems to

[swift-evolution] Should closures support inout parameters?

I was writing some code that would allow transformations of values as part of an expression, and I came across a strange error: /// Returns the operand after a given transformation. /// /// Example: `let newRect = myRect << { $0.origin.x += 3 }` func << (given: T, transformation: (inout T) ->

Re: [swift-evolution] try? shouldn't work on non-method-call

I do think that the status quo is good for try? precedence and such, but how about the original problem? The code was hard to work with because it used a double nested Optional. If you really don’t care about the reason that code failed, then a single optional should be returned. There’s

[swift-evolution] Allow use of ; in anonymous closures

Okay, I currently love closure syntax, but something doesn’t sit right with me. Why can’t I write… [6,5].map { n in; n+1 } …where there’s a semicolon after the parameter list? I think it looks better, and should at least be allowed (not required).

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Okay, I’m actually confused about the current state of things. Earlier, this was introduced: // This function is silly, // but useful functions may take a similar form func foo(x: Int?) -> Int? { guard let x = x else { return 0 } return x > 12 ? nil : x + 1 } let a: Int? = nil for i in

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

Great point; an infinite loop syntax would make a lot of sense. It seems good for it to have its own syntax, considering you must have a `break` or `return` to escape it. `while true { }` provides the same functionality, though it seems a bit less direct in its purpose than `repeat { }`

[swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

Good morning, Swift community! I’ve come across a situation a number of times where I write code that has to try something one or more times using a `repeat…while` loop and the condition relies upon variables that should be declared within the scope of the loop. repeat { let success =