Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I’ll fix that. I also forgot to change Impact on existing code section. I’ll do that when Austin had time to look at it. This proposal will break protocol A: class {} if we get protocol A: Any {} as replacement. --  Adrian Zubarev Sent with Airmail Am 23. Mai 2016 bei 02:52:31, Matthew

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Bikeshedding: Is it grammatically possible (or even desirable) to skip the “any” token and just have something like this: var view: init(view: ) {} if let mergedValue = button as? {} let a:

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Fixed a few things: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md Tell me if I left out any topic or detail. --  Adrian Zubarev Sent with Airmail Am 23. Mai 2016 bei 12:08:45, Adrian Zubarev

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Looks pretty good. Just one minor correction. Under not valid examples that may be supported in the future you have this: extension A where Self == UIView Where you should have this: extension A where Self : UIView Sent from my iPad > On May 21, 2016, at 7:42 AM, Adrian Zubarev via

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md @Austin: I used some peaces of your enhancement proposal and you’re co-author

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Regards (From mobile) > On May 17, 2016, at 7:40 PM, Adrian Zubarev via swift-evolution > wrote: > >> You don’t seem to be tackling the case of “A Collection whose Element type >> is String”. If we’re generalizing the current “protocol<>” notion, why not >> make

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I really would like to understand what you was trying to tell me. :) My English is a little rusty to understand every piece of someone's thought. By any chance someone could propose your ideas as an enhancement/upgrade of my `Any<>` mechanism later on? I mean like Joe did with removing `.self`

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 17, 2016, at 1:02 PM, Douglas Gregor via swift-evolution > wrote: > > >>> On May 17, 2016, at 10:40 AM, Adrian Zubarev >>> wrote: >>> >>> You don’t seem to be tackling the case of “A Collection whose

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 17, 2016, at 1:11 PM, Austin Zheng via swift-evolution > wrote: > > I'd like to take a shot at writing such a proposal. At some point improved > existential support will need to go through review, so we might as well. > Really happy to

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 10:40 AM, Adrian Zubarev > wrote: > >> You don’t seem to be tackling the case of “A Collection whose Element type >> is String”. If we’re generalizing the current “protocol<>” notion, why not >> make it as powerful as a generic

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

You don’t seem to be tackling the case of “A Collection whose Element type is String”. If we’re generalizing the current “protocol<>” notion, why not make it as powerful as a generic signature, with the ability to specify same-type constraints and conformances on associated types? - Doug

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution > wrote: > > So basically everyone start to like by the core team suggested `Any<>` name > of the proposed mechanism. I’ll rename it when I get home. ;) Definitely happy to see this proposal being

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

So basically everyone start to like by the core team suggested `Any<>` name of the proposed mechanism. I’ll rename it when I get home. ;) I don't think Either is a good name.  That implies 2 cases (either this or that).  Maybe 'OneOf' would be better. Since that might be or be not a different

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

But don't you mean the union type of all possible Collection types when you write Any? I suggested `all<>` for the intersection type, and `any<>` for the union type, so that would be the same, wouldn't it? Thats exactly how I understand out situation by now. I was confused by Thorsten's

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I totally agree. Being able to work properly with existentials (and the other generics stuff from the generics manifesto) is more important for Swift than adding something like Ceylon's union and intersection types (even though I am a fan of them :-) -Thorsten Am 17. Mai 2016 um 09:09

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Am 17. Mai 2016 um 08:55 schrieb Brent Royal-Gordon : But don't you mean the union type of all possible Collection types when you write Any? No, I mean "an existential capable of holding any Collection". I agree but I think this is just a generalization of type

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

What do you mean by "go before review"? I moved the proposal to a new thread: [Proposal] New mechanism to combine Types with/or Protocols Feel free to read the formatted document, provide me some feedback and point me to typos if you spot any. I'll add the possibility to allow multiple

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

This is the proposal I'd like to see go before review, and the one I think is closest in spirit to the generics roadmap. Things like adding union types, and rewriting Swift's type system to look like Scala's, have very little to do with better representations of existentials, and belong in a

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> But don't you mean the union type of all possible Collection types when you > write Any? No, I mean "an existential capable of holding any Collection". If I write Any, I mean "an existential capable of holding any Equatable Collection". If I write Any

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

But don't you mean the union type of all possible Collection types when you write Any? I suggested `all<>` for the intersection type, and `any<>` for the union type, so that would be the same, wouldn't it? -Thorsten Am 17.05.2016 um 07:10 schrieb Brent Royal-Gordon via swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> We've been over this a few times before on the list. I personally like naming > this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and > "AnySequence". I also see Thorsten (and in the past Brent's?) argument for > calling it "all" or "All", because it's enforcing multiple

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> Am 16.05.2016 um 21:29 schrieb Thorsten Seitz via swift-evolution > : > > >>> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution >>> : >>> >>> I think an important point is that `all<>` should NOT be restricted to >>>

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution > : > >> I think an important point is that `all<>` should NOT be restricted to >> having only one reference or value type! > > This is a little problematic and I’m not a compiler expert so from my

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I’ve rewritten my proposal towards the Generic Manifesto for Swift 3. I’ve polished a lot of thoughts to make everything as clear as possible. I still have to write Motivation and Proposed solution, but everything else seems to be rock solid - I’d say. Again `All<>` should not intersect but

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I think an important point is that `all<>` should NOT be restricted to having only one reference or value type! This is a little problematic and I’m not a compiler expert so from my perspective I could allow that but in a different way you see it (I’ll explain below). Ceylon does not have any

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I think an important point is that `all<>` should NOT be restricted to having only one reference or value type! Ceylon does not have any restrictions like that. You can form the type intersection of String and Integer for example, which are both classes in Ceylon and because Ceylon like Swift

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> Am 14.05.2016 um 20:08 schrieb Thorsten Seitz via swift-evolution > : > >> protocols conformance of `type<>` is tested with the actual type `type<>` >> not with the first element of `type<>` (hard to describe this one, does this >> makes sense to you?) > > The

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Thank you for pointing me to the right reading. I just read both pages: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md https://github.com/apple/swift/blob/master/docs/Generics.rst I’ll have to rewrite my proposal a bit. Btw. is there any better name for Ceylon `Any<>`?

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

That makes sense, thanks for pointing out a possibility I missed! Austin On Sat, May 14, 2016 at 11:34 AM, Vladimir.S wrote: > On 14.05.2016 21:20, Austin Zheng wrote: > >> Yes, this is theoretically possible, but why is it useful? (I am genuinely >> curious.) >> > > I just

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

On 14.05.2016 21:20, Austin Zheng wrote: Yes, this is theoretically possible, but why is it useful? (I am genuinely curious.) I just showing that we *can* invent the situation when checking for struct have a sense. Not more, not less. I'm not going to discuss if that can have

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Union types are to enums as tuples are to structs. There's room for both in the language. Sometimes it makes sense to have a more formalized construct that has specific semantics (like an error type) and methods that operate upon that type. Sometimes, you just want an int OR a string. On Sat, May

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Yes, this is theoretically possible, but why is it useful? (I am genuinely curious.) If the intention is to allow B to be a user-defined extension point for T, this goes back to the core team's arguments (in the thread about optional protocol requirements) about why having checking for

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

FWIW, yes, protocols available for struct are known at compile-time, but could be unknown at the *moment of writing* the code. What I mean: Step 1. I write source code: protocol A {} protocol B {} struct S:A {} func f(a: A) { if a is struct {...} // I expect that S could be conformed

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> Am 13.05.2016 um 17:25 schrieb Adrian Zubarev via swift-evolution > : > > Lets sum things up before I try to write a draft proposal for this feature > `type<>` aka `all<>`. > > Is this feature out of scope for Swift 3? > > From my point of view it’s definitely

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> func f(obj: A) {..} > if obj is A {...} > obj2 = obj as! A > > (but I still don't understand real use case of things like (String | Int)) Ceylon has already been mentioned: It uses the concept for its optionals. Swift uses enums, and those could be made obsolete by union types.

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I’ve done some progress on the draft proposal. There are still a few things to fill, but now it should be clear what `all<>` will solve (empty cells in the table) and what types it might produce (equivalent refined type).  `protocol<>` could completely be replaced with `all<>`. I have rewritten

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I apologize for any possible flood (if there is any restriction in this mail list). One other example that comes to mind, where I can’t really tell if this would be possible to express with `struct<>`, can be defined outside of the generic scope just like `class`

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I don't think the struct functionality makes much sense. There are two ways you can use the struct<...> construct: So does `enum<>` makes not much sense, I guess? I can’t think of any use-case were `enum<>` could do something what `struct<>` can’t. 1. struct

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

This is certainly a detailed and well-considered proposal. I don't think the struct functionality makes much sense. There are two ways you can use the struct<...> construct: 1. struct. In this case the struct<...> representation is unnecessary; the

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

If anyone is interested, I started a draft proposal with detailed design here:  https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-merging-types-with-protocols.md I didn’t post it here, because it is a bit huge and could lose its markdown formats. `all<>` is always bold,

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

You asked for any example, I give it to you ;-) (as I said, it is syntactical, just to show that such struct<> can be used to test some struct for conforming to protocol, that was not conformed at writing time) Probably we can invent useful examples for this struct<> - but I don't believe it

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

As we can(as example) expect that in 3rd party code someone will do:  extension StructA: ExtraProtocol1 {  func bar() {}  }  extension StructB: ExtraProtocol2 {  func blort() {}  }  Can we really do that? I mean, I thought about that myself but I came to the conclusion that this scenario is

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Hmm.. What about such synthetic scenario: at the moment of writing our code we have: public protocol MyProtocol { func foo() } public struct StructA:MyProtocol { func foo() } public struct StructB:MyProtocol { func foo() } and have public protocol ExtraProtocol1 { func bar() }

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

'struct<>' does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol<> already covers this. I think this is not correct. Lets check this example: func foo(value: SomeProtocol) {     if let a = value as? struct {

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

'struct<>' does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol<> already covers this. I think this is not correct. Lets check this example: func foo(value: SomeProtocol) {     if let a = value as? struct {

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Btw, if we'd have separate class<> and struct<> - we'd be able to have method to separate reference type from value type. We can write now : print(c is protocol<>) and we'd can: print(c is class<>) print(c is struct<>) Just thoughts.. On 13.05.2016 20:04, Vladimir.S wrote: On 13.05.2016

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

As Thorstan forgot to resend his message to the list, here it is (read below). It should make things about `any<>` more clear. ——— func f(obj: class) {..} if obj is class {..} obj2 = obj as! class   and yes, probably

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 13, 2016, at 10:33 AM, Adrian Zubarev via swift-evolution > wrote: > >> >> But maybe we should consider generalizing this to type operators. The '?' >> For optional could then be a postfix type operator. And we could define our >> own type operators for

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

IMO it will be nice to have ability to write: func f(obj: A) {..} if obj is A {...} obj2 = obj as! A (but I still don't understand real use case of things like (String | Int)) Btw, as we have `protocol` keyword for this feature to couple protocols, why we can't have `class` keyword to merge

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Lets sum things up before I try to write a draft proposal for this feature `type<>` aka `all<>`. Is this feature out of scope for Swift 3? From my point of view it’s definitely not.  Is the name `type<>` really that bad for the compiler? Here I’m not sure, because that is out of my

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 13, 2016, at 9:21 AM, Tony Allevato via swift-evolution > wrote: > > I think there would be a certain elegance to allowing Boolean type > expressions wherever types are currently allowed, so `A & B` being a > replacement for

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I think there would be a certain elegance to allowing Boolean type expressions wherever types are currently allowed, so `A & B` being a replacement for `protocol` might look nice, and then extend that to allow concrete types as well. Then, if Swift ever decided to support union types, the

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

We've been over this a few times before on the list. I personally like naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and "AnySequence". I also see Thorsten (and in the past Brent's?) argument for calling it "all" or "All", because it's enforcing multiple constraints.

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I don’t get the part how `all<>` should allow `any<>`. Could you explain that a little bit in detail (I’m not familiar with Ceylon)? >From my point of view `any<>` is something different that I pitched here. >`any<>` could be proposed in its own thread, because it is way different than

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Ceylon uses „&" for intersection types, i.e. SomeRealClass & SomeProtocol and the bar („|“) for union types, i.e. String | Int That has proven to be very lightweight and readable in Ceylon where it is heavily used to good effect. I agree with you that

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I'm +1 on this. It seems like it would solve the issue of Objective-C APIs losing their protocol conformances on properties/arguments/return values when they're added to a class, like UIView. That always seemed like a major hole in the cross-language support and when writing ObjC libraries I've

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

protocol  protocol  This feels really odd to me.  `type` is more clear I’d say. I think this would be a good addition to the type system and allow us to build more complex and type save code. But still I’d

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I feel like this could be a useful feature. We can right now couple protocols protocol A { func a() } protocol B { func b() } func z(o: protocol) { o.a() o.b() } let o = some as! protocol o.a() o.b() But how to be if we need to specify some class/struct in addition to

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sorry for pushing this back, but I really would like to read any feedback for this idea of mine. ;) --  Adrian Zubarev Sent with Airmail Am 4. Mai 2016 bei 22:38:33, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: This one have bothered me for days, since the idea came to my mind.

[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

This one have bothered me for days, since the idea came to my mind. I don't want to be too futuristic so here are my first thoughts. What if Swift 3 would have the ability to merge types and protocols together? Sure we will see generic typealias in Swift 3 but it doesn't allow us merge value