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

[Adrian Zubarev via swift-evolution]

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 Johnson (matt...@anandabits.com) schrieb:

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

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 
to this proposal now. If you want to polish something feel free to submit a PR.

What else do we need in this proposal?


-- 
Adrian Zubarev
Sent with Airmail
___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Sean Heber via swift-evolution]

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

I’m not even sure there’s a huge advantage to leaving it out (avoid capturing a 
new keyword?) - just thought I’d ask!

And while I’m here asking about (likely very silly) things, I wanted to note 
that the < and > symbols are heavily ingrained as generics to me and this seems 
like.. not really the same kind of thing? Has the potential for confusion about 
this been considered at all? It’s almost like what is being expressed is, 
“here’s a set/collection of requirements” and, in that case, it almost seems 
like it should look more like an array:

var view: [UIView, SomeProtocol]
init(view: [UIView, SomeProtocol]) {}
if let mergedValue = button as? [UIView, SomeProtocol] {}
let a: [UIScrollView, [UITableView, [UIView, ProtocolA]]]

Would that lead to a better syntax if such things as generic protocols were 
possible (assuming they are even desirable)? Example:

let a: [UIView, MyProtocol]

l8r
Sean - who might just be confused about things due to a lack of attention 
spa... ooh shiny things!


> On May 23, 2016, at 3:15 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 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 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> 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 Johnson (matt...@anandabits.com) 
>> schrieb:
>> 
>>> 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 swift-evolution 
>>>  wrote:
>>> 
 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 to this proposal now. If you want to polish something feel free 
 to submit a PR.
 
• What else do we need in this proposal?
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 ___
 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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 (adrian.zuba...@devandartist.com) 
schrieb:

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 Johnson (matt...@anandabits.com) schrieb:

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

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 
to this proposal now. If you want to polish something feel free to submit a PR.

What else do we need in this proposal?


-- 
Adrian Zubarev
Sent with Airmail
___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Matthew Johnson via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> 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 
> to this proposal now. If you want to polish something feel free to submit a 
> PR.
> 
> What else do we need in this proposal?
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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 
to this proposal now. If you want to polish something feel free to submit a PR.

What else do we need in this proposal?


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

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 it as powerful as a generic signature, with the ability to specify 
>> same-type constraints and conformances on associated types?
>> 
>> - Doug
> 
> Which part of the manifesto did I left out? ^^ Could you provide a quick 
> pseudo code example?
> 
> Do you mean something like `Any`? I’m not 
> sure where I should consider such a scenario, maybe at future directions?

Very reminiscent of xpath...

Any

a lot more concise though


> 
> If you’d like me to think about some specific cases I may have missed, I’d be 
> happy if you could point the right reading (or specific section of it). 
> 
> If `Any<>` could get more powerful so let it be. :)
> 
> I’m about to rewrite a few things to match `Any<>`.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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` which 
implies the ability of parsing expressions after 'as' and 'is' instead of just 
types.

I’d update my document soon at let you guys have a quick look over it before 
I’ll submit a pull request. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 20:02:35, Douglas Gregor (dgre...@apple.com) schrieb:


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 signature, with the ability to specify same-type 
constraints and conformances on associated types?

- Doug

Which part of the manifesto did I left out? ^^ Could you provide a quick pseudo 
code example?

Do you mean something like `Any`? I’m not 
sure where I should consider such a scenario, maybe at future directions?

That’s the part I’m referring to, yes. I just realized that your proposal isn’t 
lifting the restrictions on protocols with Self types or associated types, so 
my suggestion doesn’t make sense for your proposal without a significant 
increase in scope.

- Doug

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

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

[Matthew Johnson via swift-evolution]

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 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
>> 
>> Which part of the manifesto did I left out? ^^ Could you provide a quick 
>> pseudo code example?
>> 
>> Do you mean something like `Any`? I’m 
>> not sure where I should consider such a scenario, maybe at future directions?
> 
> That’s the part I’m referring to, yes. I just realized that your proposal 
> isn’t lifting the restrictions on protocols with Self types or associated 
> types, so my suggestion doesn’t make sense for your proposal without a 
> significant increase in scope.

Another related issue is having the Any type conform to all of the protocols it 
contains (should be easier than here than in the general case since there are 
no Self or associated types).  Would that be appropriate to add or do you think 
that would be a separate proposal?

> 
>   - Doug
> 
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Matthew Johnson via swift-evolution]

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 see this get started.  I'm willing to help if you need it...

> Austin
> 
>> On Tue, May 17, 2016 at 11:02 AM, 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 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
>>> 
>>> Which part of the manifesto did I left out? ^^ Could you provide a quick 
>>> pseudo code example?
>>> 
>>> Do you mean something like `Any`? I’m 
>>> not sure where I should consider such a scenario, maybe at future 
>>> directions?
>> 
>> That’s the part I’m referring to, yes. I just realized that your proposal 
>> isn’t lifting the restrictions on protocols with Self types or associated 
>> types, so my suggestion doesn’t make sense for your proposal without a 
>> significant increase in scope.
>> 
>>  - Doug
>> 
>> 
>> ___
>> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Douglas Gregor via swift-evolution]

> 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 signature, with the ability to specify 
>> same-type constraints and conformances on associated types?
>> 
>> - Doug
> 
> Which part of the manifesto did I left out? ^^ Could you provide a quick 
> pseudo code example?
> 
> Do you mean something like `Any`? I’m not 
> sure where I should consider such a scenario, maybe at future directions?

That’s the part I’m referring to, yes. I just realized that your proposal isn’t 
lifting the restrictions on protocols with Self types or associated types, so 
my suggestion doesn’t make sense for your proposal without a significant 
increase in scope.

- Doug

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

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

[Adrian Zubarev via swift-evolution]

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

Which part of the manifesto did I left out? ^^ Could you provide a quick pseudo 
code example?

Do you mean something like `Any`? I’m not 
sure where I should consider such a scenario, maybe at future directions?

If you’d like me to think about some specific cases I may have missed, I’d be 
happy if you could point the right reading (or specific section of it). 

If `Any<>` could get more powerful so let it be. :)

I’m about to rewrite a few things to match `Any<>`.

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 discussed (and happier if it uses 
“Any<>” :)).

> 
>> 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 proposal some day I guess we’d be 
> safe to call it `OneOf` for the time being.
> 
> Would you mind to go over the rules I suggested? Do we need the ability to 
> provide multiple reference/value types? I’d say no we don’t, to reduce 
> confusion (see my proposal).
> 
> https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md
>  
> 
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

> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Mai 2016 bei 15:34:10, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
 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 `intersection` first, but now I see that he meant the 
>>> intersection between dynamic type and the whole set of constraints provided 
>>> by `All<…>`. I thought about about the constraints union compared to the 
>>> dynamic type, which is most likely the same thing.
>>> 
>>> In my proposal I reserved the name `Any<>` for future directions, but noted 
>>> that we still might choose `Any<…>` for the proposed `All<…>` and then name 
>>> `Any<…>` described by Thorsten as `Either<…>`.
>>> 
>> 
>> I agree with Brent's concept of Any.  That feels Swifty, following the 
>> convention established by the type-erasing wrappers currently in the 
>> standard library.  
>> 
>> I don't think Either is a good name.  That implies 2 cases (either this or 
>> that).  Maybe 'OneOf' would be better.
>>> 
  >> 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.
>>> 
 > 
 > I have suggested `all<>` in the past, but I now favor `Any`, because 
 > that allows it to be unified with the universal supertype `Any`, 
 > `Any`, and things like `Any` to forge the One 
 > Existential Syntax to rule them all.
>>> 
>>> I considered `Any<>` as an alternative and personally I don’t have anything 
>>> against that little change. I still don’t like `AnyObject` because it uses 
>>> `Object` instead of `Class`, where `AnyClass` is `AnyObject.Type`. This is 
>>> way to confusing if you ask me. I’d rename both into `ClassInstance` == 
>>> `AnyObject` and `ClassType` == `AnyClass`. If Swift one day might introduce 
>>> `struct` and `enum` keywords that are generalized like `class` (could be) 
>>> what name would you choose? Compared to `AnyClass` typealias `AnyStruct` 
>>> would be `AnyXYZ.Type`. The only type I like which uses `Any` as its prefix 
>>> is `Any` itself. 
>>> 
>>> But I guess this is something the core team will decide.
>>> 
>>> If there is no feedback towards the document I wrote anymore, I’ll submit a 
>>> pull request later this day. (Note: I’ll add some small changes in the 
>>> alternatives section about dropping the restriction of a single 
>>> reference/value type within the angle brackets).
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 17. Mai 2016 bei 07:17:21, Thorsten Seitz via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 

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

[Adrian Zubarev via swift-evolution]

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 proposal some day I guess we’d be 
safe to call it `OneOf` for the time being.

Would you mind to go over the rules I suggested? Do we need the ability to 
provide multiple reference/value types? I’d say no we don’t, to reduce 
confusion (see my proposal).

https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 15:34:10, Matthew Johnson (matt...@anandabits.com) schrieb:



Sent from my iPad

On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution 
 wrote:

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 `intersection` first, but now I see that he meant the intersection 
between dynamic type and the whole set of constraints provided by `All<…>`. I 
thought about about the constraints union compared to the dynamic type, which 
is most likely the same thing.

In my proposal I reserved the name `Any<>` for future directions, but noted 
that we still might choose `Any<…>` for the proposed `All<…>` and then name 
`Any<…>` described by Thorsten as `Either<…>`.


I agree with Brent's concept of Any.  That feels Swifty, following the 
convention established by the type-erasing wrappers currently in the standard 
library.  

I don't think Either is a good name.  That implies 2 cases (either this or 
that).  Maybe 'OneOf' would be better.

 >> 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.
> 
> I have suggested `all<>` in the past, but I now favor `Any`, because that 
> allows it to be unified with the universal supertype `Any`, `Any`, and 
> things like `Any` to forge the One Existential Syntax to rule 
> them all.
I considered `Any<>` as an alternative and personally I don’t have anything 
against that little change. I still don’t like `AnyObject` because it uses 
`Object` instead of `Class`, where `AnyClass` is `AnyObject.Type`. This is way 
to confusing if you ask me. I’d rename both into `ClassInstance` == `AnyObject` 
and `ClassType` == `AnyClass`. If Swift one day might introduce `struct` and 
`enum` keywords that are generalized like `class` (could be) what name would 
you choose? Compared to `AnyClass` typealias `AnyStruct` would be 
`AnyXYZ.Type`. The only type I like which uses `Any` as its prefix is `Any` 
itself. 

But I guess this is something the core team will decide.

If there is no feedback towards the document I wrote anymore, I’ll submit a 
pull request later this day. (Note: I’ll add some small changes in the 
alternatives section about dropping the restriction of a single reference/value 
type within the angle brackets).

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 07:17:21, Thorsten Seitz via swift-evolution 
(swift-evolution@swift.org) schrieb:

___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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 `intersection` first, but now I see that he meant the intersection 
between dynamic type and the whole set of constraints provided by `All<…>`. I 
thought about about the constraints union compared to the dynamic type, which 
is most likely the same thing.

In my proposal I reserved the name `Any<>` for future directions, but noted 
that we still might choose `Any<…>` for the proposed `All<…>` and then name 
`Any<…>` described by Thorsten as `Either<…>`.


 >> 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.
> 
> I have suggested `all<>` in the past, but I now favor `Any`, because that 
> allows it to be unified with the universal supertype `Any`, `Any`, and 
> things like `Any` to forge the One Existential Syntax to rule 
> them all.
I considered `Any<>` as an alternative and personally I don’t have anything 
against that little change. I still don’t like `AnyObject` because it uses 
`Object` instead of `Class`, where `AnyClass` is `AnyObject.Type`. This is way 
to confusing if you ask me. I’d rename both into `ClassInstance` == `AnyObject` 
and `ClassType` == `AnyClass`. If Swift one day might introduce `struct` and 
`enum` keywords that are generalized like `class` (could be) what name would 
you choose? Compared to `AnyClass` typealias `AnyStruct` would be 
`AnyXYZ.Type`. The only type I like which uses `Any` as its prefix is `Any` 
itself. 

But I guess this is something the core team will decide.

If there is no feedback towards the document I wrote anymore, I’ll submit a 
pull request later this day. (Note: I’ll add some small changes in the 
alternatives section about dropping the restriction of a single reference/value 
type within the angle brackets).

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 07:17:21, Thorsten Seitz via swift-evolution 
(swift-evolution@swift.org) schrieb:___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

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 schrieb Austin Zheng :


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 follow-up proposal.

Austin


On May 16, 2016, at 11:55 PM, Brent Royal-Gordon via swift-evolution 
 wrote:


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, I mean "an existential capable 
of holding any CounterDisplaying UITableViewCell".


If I write Any, I mean "an existential capable 
of holding any Collection with an Equatable Element".


If I write Any, I mean "An existential capable of holding any class 
instance".


If I write Any, I mean "An existential capable of holding anything".


Union types have nothing to do with it.


--
Brent Royal-Gordon
Architechies


___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

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 unions as they are 
currently possible in Ceylon.



´A | B´ in Ceylon notation (or any in proposed Swift notation) is a union 
type meaning a type capable of holding an A or a B.
Any is a type capable of holding any Collection, i.e. something 
like `forall E. Collection where Element == E`. If I could enumerate all possible 
values for `E` then I could write this as an explicit type union (which would be very 
very long, of course :-)

Something like: (Collection where Element == Int) | (Collection where Element 
== String) | ...





If I write Any, I mean "an existential capable of holding any 
Equatable Collection".


Which is a type union of Equatable and the existential representing any 
Collection.




If I write Any, I mean "an existential capable 
of holding any CounterDisplaying UITableViewCell".


Which would be written as type union `UITableViewCell | CounterDisplaying` in 
Ceylon.



If I write Any, I mean "an existential capable 
of holding any Collection with an Equatable Element".

If I write Any, I mean "An existential capable of holding any class 
instance".

If I write Any, I mean "An existential capable of holding anything".

Union types have nothing to do with it.


IMHO they are a just special case where I can write down all types forming the 
union explicitly whereas an existential uses a type variable which can assume 
all types (or all types of a constrained subset).


Actually I like this generalization very much (although I think the type operators `|` and 
`&` are much easier to read than `Any<>` and `All<>` but they don't generalize 
to existentials).



-Thorsten

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

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

[Adrian Zubarev via swift-evolution]

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 reference/value types within the 
angle brackets as a considered alternative. 

I finally understand what Thorsten meant with this example: 

func intersect(set1: Set, set2: Set) -> Set> 

If T == U we'll get All == T 

Or simply: 

func intersect(set1: Set, set2: Set) -> Set 

This makes more sense to me. :)

-- 
Adrian Zubarev 

Am 17. Mai 2016 um 09:09:55, Austin Zheng via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

> 
> 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 follow-up proposal.
> 
> Austin
> 
> > On May 16, 2016, at 11:55 PM, Brent Royal-Gordon via swift-evolution 
> >  wrote:
> > 
> > > 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, I mean "an existential 
> > capable of holding any CounterDisplaying UITableViewCell".
> > 
> > If I write Any, I mean "an 
> > existential capable of holding any Collection with an Equatable Element".
> > 
> > If I write Any, I mean "An existential capable of holding any class 
> > instance".
> > 
> > If I write Any, I mean "An existential capable of holding anything".
> > 
> > Union types have nothing to do with it.
> > 
> > --
> > Brent Royal-Gordon
> > Architechies
> > 
> > ___
> > 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

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 follow-up proposal.

Austin

> On May 16, 2016, at 11:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> 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, I mean "an existential 
> capable of holding any CounterDisplaying UITableViewCell".
> 
> If I write Any, I mean "an existential 
> capable of holding any Collection with an Equatable Element".
> 
> If I write Any, I mean "An existential capable of holding any class 
> instance".
> 
> If I write Any, I mean "An existential capable of holding anything".
> 
> Union types have nothing to do with it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Brent Royal-Gordon via swift-evolution]

> 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, I mean "an existential 
capable of holding any CounterDisplaying UITableViewCell".

If I write Any, I mean "an existential 
capable of holding any Collection with an Equatable Element".

If I write Any, I mean "An existential capable of holding any class 
instance".

If I write Any, I mean "An existential capable of holding anything".

Union types have nothing to do with it.

-- 
Brent Royal-Gordon
Architechies

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

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

[Thorsten Seitz via swift-evolution]

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 
:

>> 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.
> 
> I have suggested `all<>` in the past, but I now favor `Any`, because that 
> allows it to be unified with the universal supertype `Any`, `Any`, and 
> things like `Any` to forge the One Existential Syntax to rule 
> them all.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Brent Royal-Gordon via swift-evolution]

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

I have suggested `all<>` in the past, but I now favor `Any`, because that 
allows it to be unified with the universal supertype `Any`, `Any`, and 
things like `Any` to forge the One Existential Syntax to rule them 
all.

-- 
Brent Royal-Gordon
Architechies

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

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

[Thorsten Seitz via swift-evolution]

> 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 
>>> 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 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 only knows single inheritance between 
>>> classes, the result is simply `Nothing` (the bottom type which has no 
>>> elements). So there is no need to forbid this explicitly, because the types 
>>> work out just fine.
>> 
>> If I remember correctly someone said that `Ceylon` does use `all` and `any` 
>> for its Optional?! We can’t to do this in Swift as far as I know our 
>> playground.
>> 
>> We don’t have `Nothing` in Swift. The counterpart would be `Optional` but 
>> such a type is made explicit by `?` symbol like `Type? == Optional` 
>> and the only equivalent to `Nothing` would be `nil`.
>> 
> `Nothing` is the bottom type, i.e. the intersection of all types. It has no 
> members.
> `Nothing` has nothing to do with optionals. Optionals in Ceylon are type 
> unions with the type `Null` which has a single member called `null` (= 
> Swift’s nil).
> 
> Maybe this proposal should start with forbidding creating `All<>` expressions 
> which would evaluate to `Nothing` and a later proposal could introduce the 
> bottom type.
> 
>> That been said, if `All<>` would always intersect (what I haven’t proposed 
>> here at all) we can’t replace `protocol<>` with `All<>` because if we look 
>> at two distinct protocols `A` and `B` and try to merge them into a type 
>> `All` would resolve in `implicit nil` where the old fashion way is not 
>> `protocol`.
>> 
> I don’t know from where you got `implicit nil`. Seems I was a bit unclear :-)
> All is the intersection type of A and B, i.e. a type which conforms to 
> A *and* B.
> Only for cases where A and B are *classes* which do *not* share an 
> inheritance relation the result of All is `Nothing` (the empty bottom 
> type). This is a special case. The reason is that because of single 
> inheritance it is impossible to define a subtype of two different class 
> hierarchies.
> If A and B are structs the result of All is `Nothing` as well, because 
> structs are not subtypeable at all. Note that All will just 
> be StructA, though.
> If at least one of A and B is a protocol it is always possible to define a 
> type that conforms to A and B.
> 
>> By the way, really an `implicit nil`? This is not a great idea if you ask 
>> me. 
>> 
>> You may have a look at this document: 
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
>> 
>> `All == implicit nil` (your way) while it probably `All> Int>? == nil` would serve your wished behavior, but again I wasn’t proposing 
>> on solving this issue here. I’d like to solve this problem 
>> https://openradar.appspot.com/20990743 and open the door for `AnyStruct`, 
>> `AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
>> `Any<>` combined with my `All<>` might create.
>> 
>> If we allow multiple reference and value types for `All<>` this will only 
>> work with subtypeable types, because as I already described above 
>> `All` can’t be merged.
>> 
> Yes, as long as subtyping structs is not possible in Swift All StructB> would be `Nothing` (again: this is not the type of `nil`).
> 
>> A scenario that will work might look like this:
>> 
>> class A {} class B: A {} class C: B {}
>> 
>> `All` from the given types and my understanding the compile could 
>> and should infer `C` from here (not `B` compared to your example below).
>> 
> 
> Oops, sorry, you are right. I again made the error of confusing intersection 
> types (all<>) with union types (any<>). Grrr. I’m used to the type operators, 
> that’s my only excuse…
> 
>> To sum up a little we would have these facts:
>> 
>> - for subtypeable types the compile will search the highest type from the 
>> inheritance path and ignore all other lower base types (for `All` the 
>> compile would infer `B == All == All`)
>> 
> With `highest` you mean `most specialized`, right? (for me that’s the lowest 
> type :-)
> 
>> - the oder of types should not matter because of the previous fact
>> 
> Exactly.
> 
>> That been said do we still need the whole inheritance branch inside of 
>> `All<>`? I don’t think so.
>> 
> Right, the whole branch is definitely not needed.
> 
>> Furthermore if we definitely should ignore order of `Types` 

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

[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 
>> 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 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 only knows single inheritance between 
>> classes, the result is simply `Nothing` (the bottom type which has no 
>> elements). So there is no need to forbid this explicitly, because the types 
>> work out just fine.
> 
> If I remember correctly someone said that `Ceylon` does use `all` and `any` 
> for its Optional?! We can’t to do this in Swift as far as I know our 
> playground.
> 
> We don’t have `Nothing` in Swift. The counterpart would be `Optional` but 
> such a type is made explicit by `?` symbol like `Type? == Optional` and 
> the only equivalent to `Nothing` would be `nil`.
> 
`Nothing` is the bottom type, i.e. the intersection of all types. It has no 
members.
`Nothing` has nothing to do with optionals. Optionals in Ceylon are type unions 
with the type `Null` which has a single member called `null` (= Swift’s nil).

Maybe this proposal should start with forbidding creating `All<>` expressions 
which would evaluate to `Nothing` and a later proposal could introduce the 
bottom type.

> That been said, if `All<>` would always intersect (what I haven’t proposed 
> here at all) we can’t replace `protocol<>` with `All<>` because if we look at 
> two distinct protocols `A` and `B` and try to merge them into a type `All B>` would resolve in `implicit nil` where the old fashion way is not 
> `protocol`.
> 
I don’t know from where you got `implicit nil`. Seems I was a bit unclear :-)
All is the intersection type of A and B, i.e. a type which conforms to A 
*and* B.
Only for cases where A and B are *classes* which do *not* share an inheritance 
relation the result of All is `Nothing` (the empty bottom type). This is 
a special case. The reason is that because of single inheritance it is 
impossible to define a subtype of two different class hierarchies.
If A and B are structs the result of All is `Nothing` as well, because 
structs are not subtypeable at all. Note that All will just 
be StructA, though.
If at least one of A and B is a protocol it is always possible to define a type 
that conforms to A and B.

> By the way, really an `implicit nil`? This is not a great idea if you ask me. 
> 
> You may have a look at this document: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md 
> 
> `All == implicit nil` (your way) while it probably `All Int>? == nil` would serve your wished behavior, but again I wasn’t proposing 
> on solving this issue here. I’d like to solve this problem 
> https://openradar.appspot.com/20990743 
>  and open the door for `AnyStruct`, 
> `AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
> `Any<>` combined with my `All<>` might create.
> 
> If we allow multiple reference and value types for `All<>` this will only 
> work with subtypeable types, because as I already described above 
> `All` can’t be merged.
> 
Yes, as long as subtyping structs is not possible in Swift All would be `Nothing` (again: this is not the type of `nil`).

> A scenario that will work might look like this:
> 
> class A {} class B: A {} class C: B {}
> 
> `All` from the given types and my understanding the compile could 
> and should infer `C` from here (not `B` compared to your example below).
> 
> 

Oops, sorry, you are right. I again made the error of confusing intersection 
types (all<>) with union types (any<>). Grrr. I’m used to the type operators, 
that’s my only excuse…

> To sum up a little we would have these facts:
> 
> - for subtypeable types the compile will search the highest type from the 
> inheritance path and ignore all other lower base types (for `All` the 
> compile would infer `B == All == All`)
> 
With `highest` you mean `most specialized`, right? (for me that’s the lowest 
type :-)

> - the oder of types should not matter because of the previous fact
> 
Exactly.

> That been said do we still need the whole inheritance branch inside of 
> `All<>`? I don’t think so.
> 
Right, the whole branch is definitely not needed.

> Furthermore if we definitely should ignore order of `Types` inside the angle 
> brackets like `All == All`, because it makes sense from the 
> context of creating a `Type` that is constrained to 

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

[Adrian Zubarev via swift-evolution]

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 merge and infer types if possible. There 
is no need for inheritance branches inside angle brackets (only possible with 
classes anyway).

Here is the new url: 
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md

Future direction might be promising as well. :)

-- 
Adrian Zubarev
Sent with Airmail___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 
perspective I could allow that but in a different way you see it (I’ll explain 
below).

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 only knows single inheritance between 
classes, the result is simply `Nothing` (the bottom type which has no 
elements). So there is no need to forbid this explicitly, because the types 
work out just fine.
If I remember correctly someone said that `Ceylon` does use `all` and `any` for 
its Optional?! We can’t to do this in Swift as far as I know our playground.

We don’t have `Nothing` in Swift. The counterpart would be `Optional` but such 
a type is made explicit by `?` symbol like `Type? == Optional` and the 
only equivalent to `Nothing` would be `nil`.

That been said, if `All<>` would always intersect (what I haven’t proposed here 
at all) we can’t replace `protocol<>` with `All<>` because if we look at two 
distinct protocols `A` and `B` and try to merge them into a type `All` 
would resolve in `implicit nil` where the old fashion way is not `protocol`. By the way, really an `implicit nil`? This is not a great idea if you ask 
me. 

You may have a look at this document: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

`All == implicit nil` (your way) while it probably `All? == nil` would serve your wished behavior, but again I wasn’t proposing on 
solving this issue here. I’d like to solve this problem 
https://openradar.appspot.com/20990743 and open the door for `AnyStruct`, 
`AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
`Any<>` combined with my `All<>` might create.

If we allow multiple reference and value types for `All<>` this will only work 
with subtypeable types, because as I already described above `All` can’t be merged.

A scenario that will work might look like this:

class A {}     class B: A {}     class C: B {}

`All` from the given types and my understanding the compile could and 
should infer `C` from here (not `B` compared to your example below).

To sum up a little we would have these facts:

- for subtypeable types the compile will search the highest type from the 
inheritance path and ignore all other lower base types (for `All` the 
compile would infer `B == All == All`)

- the oder of types should not matter because of the previous fact

That been said do we still need the whole inheritance branch inside of `All<>`? 
I don’t think so.

Furthermore if we definitely should ignore order of `Types` inside the angle 
brackets like `All == All`, because it makes sense from the context 
of creating a `Type` that is constrained to `A` AND `B` where AND is 
commutative. I didn’t thought of at first glance, but thanks to your examples 
it’s clear to me know.

———

If one would want to store or pass `A` from `class A: ClassB, ProtocolC` in 
some generic context and we don’t allow a second reference for `All<>` the 
following sample won’t work (generalized `class` is assumed):

`func (value: All)` but you can workaround here 
`func (value: All)` which can already be done `func 
(value: T)`

The only problem that rises up here is that we can’t store that value inside a 
non-generic `Type` with both distinct `ClassB` and `ProtocolC` constraints 
merged together. As you might guess `ProtocolC` is applied onto `A` but not on 
`B` where `All` will create a whole new type for us 
(https://openradar.appspot.com/20990743).

Furthermore you can form type intersections between reference types which 
inherit from each other. The resulting intersection type is valid and is just 
equal to the more specific type. And of course you can form type intersections 
of a reference or value type with itself (i.e. all).
Why should that be useful you may ask?

This generality is important when using intersection types with generics: let’s 
consider the type of a function forming the intersection of two sets with 
different element types:

func union(a: Set, b: Set) -> Set> { … }


Requiring all to have at most one reference or value type (which must be 
at first position) would impose some unnecessary restrictions:

Given the following:

protocol Named {}
class Person : Named {}
class Employee : Person {}

let people: Set
let otherPeople: Set
let employees: Set
let namedOnes: Set

// unnecessary restriction:
let x1 = union(namedOnes, people)  // not allowed, because result type contains 
all 
// the restriction would require us to write:
let x2 = union(people, namedOnes)  // ok, result type would be 

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

[Thorsten Seitz via swift-evolution]

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 only knows single inheritance between 
classes, the result is simply `Nothing` (the bottom type which has no 
elements). So there is no need to forbid this explicitly, because the types 
work out just fine.

Furthermore you can form type intersections between reference types which 
inherit from each other. The resulting intersection type is valid and is just 
equal to the more specific type. And of course you can form type intersections 
of a reference or value type with itself (i.e. all).

Why should that be useful you may ask?

This generality is important when using intersection types with generics: let’s 
consider the type of a function forming the intersection of two sets with 
different element types:

func union(a: Set, b: Set) -> Set> { … }


Requiring all to have at most one reference or value type (which must be 
at first position) would impose some unnecessary restrictions:

Given the following:

protocol Named {}
class Person : Named {}
class Employee : Person {}

let people: Set
let otherPeople: Set
let employees: Set
let namedOnes: Set

// unnecessary restriction:
let x1 = union(namedOnes, people)  // not allowed, because result type contains 
all 

// the restriction would require us to write:
let x2 = union(people, namedOnes)  // ok, result type would be Set> which would be simplified by the compiler to Set (Ceylon does 
this!)

// unnecessary restriction:
let x3 = union(people, employees)   // not allowed, because result type would 
contain all with two reference types

// unnecessary restriction
let x4 = union(people, otherPeople)   // not allowed, because result type 
contains all with two reference types

IMO these should all be allowed (and are possible in Ceylon). 
The result type of x1 would be Set> which would be 
simplified by the compiler to Set.
The result type of x2 would be Set> which would be 
simplified by the compiler to Set.
The result type of x3 would be Set> which would be 
simplified by the compiler to Set.
The result type of x4 would be Set> which would be 
simplified by the compiler to Set.

-Thorsten



> Am 14.05.2016 um 01:50 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> 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, because this is what we are interested in, 
> but I provided all possible combinations if the other formats would exists 
> (at least all combinations I could think of, anything else is derived from 
> these). 
> 
> `class<>` etc. can be seen as a future direction (I would say), otherwise 
> this would easily become out of scope for Swift 3. (I will  move `class<>` 
> etc. from detailed design to future direction later.)
> 
> I’d love to hear your feedback and strong arguments for the motivation part I 
> could include into this proposal.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 23:16:20, Vladimir.S (sva...@gmail.com 
> ) schrieb:
> 
>> 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 will be introduced in Swift ;-) 
>> 
>> On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote: 
>> > Can we really do that? I mean, I thought about that myself but I came to 
>> > the conclusion that this scenario is like: I was to lazy to couple this 
>> > structs to my library protocols, will you do that for me? 
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

> 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 components of type<> are unrelated and do not have to conform to each 
> other. They are just a union type. Did you mean that?

Ooops, I meant of course, the complete expression forms an *intersection* type 
(not a union type). 

To recap:

In Ceylon A & B is an intersection type which means a type that conforms to A 
*and* B. This could be written as all in Swift.
In Ceylon A | B is a union type which means a type that conforms to A *or* B 
(maybe to both but at least to one of them). This could be written as any 
in Swift.

-Thorsten


> 
> -Thorsten
> 
>> Does this proposal need more than the base `type<>`?
>> 
>> Maybe, but I think we should start with `type<>` before we will introduce a 
>> type operator for this.
>> 
>> Did I missed anything out here? 
>> 
>> PS: Feel free to help me with my English, because it’s not so well.
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com 
>> ) schrieb:
>> 
>>> 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 `|` operator naturally fits there.
>>> 
>>> One concern though would be whether parsing would get more complicated with 
>>> deeply composed expressions. If we only supported `&`, there's no real 
>>> nesting going on. But if we wanted to be forward thinking and leave the 
>>> door open for `|`, we might need to support things like `(String | Int) & 
>>> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
>>> would really complicate things (e.g., could the compiler decide easily 
>>> enough that those parentheses are part of a type expression and not a 
>>> function type?).
>>> 
>>> `all` would be a nice compromise in that case, and leave the door 
>>> open for `any` in the future. So I'd be supportive of either option.
>>> 
>>> 
>>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>>> > wrote:
>>> 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.
>>> 
>>> I will say that "type" is unlikely to see much traction simply because it 
>>> is an incredibly common name for both properties and locals. We went 
>>> through that exercise when trying to name both "static" and "dynamicType" 
>>> and decided that it would be too confusing, even if we could make the 
>>> parsing work.
>>> 
>>> The feature itself has definitely been shown to be useful when working with 
>>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>>> have it internally tracked in Radar as rdar://problem/15873071 <>.
>>> 
>>> Jordan
>>> 
>>> 
 On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
 > wrote:
 
 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 `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
 
 Here is a little example where `any<>` gets strange:
 
 func foo(value: any) -> any {
 
 // how would one use value here?
 // what about its properties
 // what will foo return and how to use the result
 }
 
 One benefit of `any<>` is the replacement of overloading, at least for the 
 type part of the function.
 
 I’d like to propose `type<>` as the base extension to the language in that 
 direction, before we’ll move forward with more complex scenarios (just 
 like Chris did with generic typealias).
 
 This function is clear that it only will work if you provide a subclass of 
 an UIView which conforms to SomeProtocol (nice addition for library 
 design).
 
 func foo(value: type) -> type {
 
 // use it as a UIView and SomeProtocol at the same type
 return value // return type works great
 

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

[Adrian Zubarev via swift-evolution]

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<>`? Maybe `Either<>`?

`Any` - "Any type that conforms to T and U“ 

Could someone explain to me what existentials suppose to be? I didn’t get that 
part from the article, where everything else made somehow sense to me. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 14. Mai 2016 bei 20:21:04, Austin Zheng via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 conformance to some requirement at 
the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the core 
team has already ruled out a number of features (user-defined variance on 
generics, generic protocols) because they don't believe in their general 
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S  wrote:
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 to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}




On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.


___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

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 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 any (or never can have at all)
> useful intention.
>
>
>> 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 conformance to some
>> requirement at the use site is a suboptimal idea.
>>
>> If the intention is to make the type system as expressive as possible, the
>> core team has already ruled out a number of features (user-defined
>> variance
>> on generics, generic protocols) because they don't believe in their
>> general
>> applicability.
>>
>> Austin
>>
>> On Sat, May 14, 2016 at 11:13 AM, Vladimir.S > > wrote:
>>
>> 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 to B
>> }
>>
>> Step 2. I give my code to someone, who can do somewhere in his
>> project:
>>
>> extension S:B{..}
>>
>>
>>
>>
>> On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
>>
>> 1. struct. In this case
>> the
>> struct<...> representation is unnecessary; the protocols that are
>> available
>> to the user are known at compile-time, and structs can't have
>> subtypes that
>> conform to additional protocols like classes can. There is an
>> example
>> marked "func boo(value: struct) /* equivalent to */
>> func
>> boo(value: SomeStruct)"; my question is why having more than two
>> ways to
>> express the same idea makes the language better, easier to use,
>> etc.
>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 any (or never can have at all) 
useful intention.




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 conformance to some
requirement at the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the
core team has already ruled out a number of features (user-defined variance
on generics, generic protocols) because they don't believe in their general
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S > wrote:

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 to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}




On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:

1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are
available
to the user are known at compile-time, and structs can't have
subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two
ways to
express the same idea makes the language better, easier to use, etc.



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

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

[Austin Zheng via swift-evolution]

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 14, 2016 at 10:58 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > 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.
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

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 conformance to some
requirement at the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the
core team has already ruled out a number of features (user-defined variance
on generics, generic protocols) because they don't believe in their general
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S  wrote:

> 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 to B
> }
>
> Step 2. I give my code to someone, who can do somewhere in his project:
>
> extension S:B{..}
>
>
>
>
> On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
>
>> 1. struct. In this case the
>> struct<...> representation is unnecessary; the protocols that are
>> available
>> to the user are known at compile-time, and structs can't have subtypes
>> that
>> conform to additional protocols like classes can. There is an example
>> marked "func boo(value: struct) /* equivalent to */ func
>> boo(value: SomeStruct)"; my question is why having more than two ways to
>> express the same idea makes the language better, easier to use, etc.
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}



On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:

1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.


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

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

[Thorsten Seitz via swift-evolution]

> 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 not. 
> 
> Is the name `type<>` really that bad for the compiler?
> 
> Here I’m not sure, because that is out of my experience. From a readers 
> perspective it’s more clear than `all<>`, I would say, even though this is a 
> perfect explanation why it should be called `all<>`:
> 
>> I also see Thorsten (and in the past Brent's?) argument for calling it "all" 
>> or "All", because it's enforcing multiple constraints.
> 
> Do we miss any rules here?
> 
> `type<>` can contain only one value-type or reference-type and n protocols
> the value-type or reference-type should always be the first element between 
> angle brackets
> `type<>` should always contain at least 2 types (one value-type or a 
> reference-type and at least one protocol)
I think type<> (or all<>) should replace protocol<>, otherwise the idea of 
having all<> and any<> loses its charm.
Is there a reason why type<> should exist in parallel to protocol<>?
> reference-types do represent a possible super/base type/class
> nesting `type<>` is not allowed, however `type<>` can contain `protocol<>`
> 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 components of type<> are unrelated and do not have to conform to each 
other. They are just a union type. Did you mean that?

-Thorsten

> Does this proposal need more than the base `type<>`?
> 
> Maybe, but I think we should start with `type<>` before we will introduce a 
> type operator for this.
> 
> Did I missed anything out here? 
> 
> PS: Feel free to help me with my English, because it’s not so well.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com 
> ) schrieb:
> 
>> 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 `|` operator naturally fits there.
>> 
>> One concern though would be whether parsing would get more complicated with 
>> deeply composed expressions. If we only supported `&`, there's no real 
>> nesting going on. But if we wanted to be forward thinking and leave the door 
>> open for `|`, we might need to support things like `(String | Int) & 
>> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
>> would really complicate things (e.g., could the compiler decide easily 
>> enough that those parentheses are part of a type expression and not a 
>> function type?).
>> 
>> `all` would be a nice compromise in that case, and leave the door open 
>> for `any` in the future. So I'd be supportive of either option.
>> 
>> 
>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>> > wrote:
>> 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.
>> 
>> I will say that "type" is unlikely to see much traction simply because it is 
>> an incredibly common name for both properties and locals. We went through 
>> that exercise when trying to name both "static" and "dynamicType" and 
>> decided that it would be too confusing, even if we could make the parsing 
>> work.
>> 
>> The feature itself has definitely been shown to be useful when working with 
>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>> have it internally tracked in Radar as rdar://problem/15873071 <>.
>> 
>> Jordan
>> 
>> 
>>> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> 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 `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
>>> 
>>> Here is a little example where `any<>` gets strange:
>>> 
>>> func foo(value: any) -> any {
>>> 
>>> // how would one use value here?
>>> // what about its properties
>>> // what will foo return 

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

[Tino Heth via swift-evolution]

> 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 the examples for `all<>` to be more specific and moved 
`class<>` etc. to future directions with some examples what can be done with 
these.

Due the fact that Swift 3 will have generic typealias and possible `any<>`, 
`struct<>` and `enum<>` in the future, we could also build `value<>` which I 
showed at the button of the proposal.

Feel free to give me some feedback. :)

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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` or `all`:

var structArray: [struct]

Would this work? This is an interesting case, where no values inside the struct 
can be reference-types!
Actually I can answer this question by myself, because `Any` is just a 
typealias for `protocol<>` and does not violate any rule here.

This also adds a few more type combinations I missed out in my proposal:

e.g. `struct` is equivalent to `struct>`

This can allow us to use any struct without the need of generic scope! Isn’t it 
great or what?

Have you ever wanted to store any class references with conformance to a 
protocol without the generic system, with this you could do so `class`: 

var classArray: [class]



Best Regards,

Adrian Zubarev



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

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

[Adrian Zubarev via swift-evolution]

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. In this case the 
struct<...> representation is unnecessary; the protocols that are available to 
the user are known at compile-time, and structs can't have subtypes that 
conform to additional protocols like classes can. There is an example marked 
"func boo(value: struct) /* equivalent to */ func boo(value: 
SomeStruct)"; my question is why having more than two ways to express the same 
idea makes the language better, easier to use, etc.
Was this clarified somewhere, I mean that value types won’t have subtypes ever? 
This would be nice to know.

We already can write the same (ugly) scenario with protocols:
protocol A {}
extension A {
     func foo() {
          print("f")
     }
}

// this is the refined design that we all use
func boo(value: A) {
     value.foo()
}

// this might be the original design  
func zoo(value: protocol) {
     boo(value)
}

struct B: A {}
let value = B()

zoo(value)
boo(value)
The main idea behind `struct<>` etc. is not to make the language complicated, 
but to add symmetry to the type system, which should already have been there 
from the beginning. Compared to the little example I just wrote, we all already 
use the refined format of the (not present) base `struct<>`.

So if value types might have subtypes one day, this wouldn’t be hard to upgrade 
I suppose. Anyways I’ll move that part of the proposal to the future direction.

2. struct. In this case struct<...> is being used as 
an add-on to the generics system to denote a 'must be value type' constraint. 
However, I think a 'T : class'-like 'struct' constraint makes more sense, both 
because it fits better with the existing 'class' constraint and because it can 
be used anywhere the generic system allows a type parameter to be constrained.  
A generic 'struct' constraint would give the currently generics system as much 
expressive power as struct<...>.
True, but I feel like there is a change incoming in that direction 
([swift-evolution] Should we rename "class" when referring to protocol 
conformance?) and I don’t think the core team will decide to introduce `T: 
class`-like `struct` or `enum` constraint. :/

struct C {

    var value: T?

    func set(value: T) {

        self.value = value

    }

}

This would be nice to have. And yes this does look way better than:

struct C> {

    […]

}

But isn’t this again a refined usage of the base format (`struct<>` in this 
case)!? 

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` or `all`:

var structArray: [struct]

Would this work? This is an interesting case, where no values inside the struct 
can be reference-types!

Overall, rather than having this be a separate feature I think it should be 
developed as part of the "Generalized Existentials" feature that is already on 
the roadmap for Swift 3. The cases where adding class<...>, struct<...>, etc 
can improve expressive power are covered by allowing variables to take 
existential types with constraints. The one big feature that Generalized 
Existentials should absorb from this proposal is allowing the representation of 
a concrete class type with protocol constraints ().
Is there any reading you can point me to, so I can include or quote it into the 
proposal?

-- 
Adrian Zubarev
Sent with Airmail

Am 14. Mai 2016 bei 06:06:12, Austin Zheng (austinzh...@gmail.com ) schrieb:


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

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

[Austin Zheng via swift-evolution]

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 protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.

2. struct. In this case struct<...> is being used
as an add-on to the generics system to denote a 'must be value type'
constraint. However, I think a 'T : class'-like 'struct' constraint makes
more sense, both because it fits better with the existing 'class'
constraint and because it can be used anywhere the generic system allows a
type parameter to be constrained. A generic 'struct' constraint would give
the currently generics system as much expressive power as struct<...>.

Overall, rather than having this be a separate feature I think it should be
developed as part of the "Generalized Existentials" feature that is already
on the roadmap for Swift 3. The cases where adding class<...>, struct<...>,
etc can improve expressive power are covered by allowing variables to take
existential types with constraints. The one big feature that Generalized
Existentials should absorb from this proposal is allowing the
representation of a concrete class type with protocol constraints
().

Best,
Austin



On Fri, May 13, 2016 at 5:16 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?
>
> Sure one could think that this protocols might be optional but the `f(p:
> MyProtocol)` function will cover this scenario.
>
> Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
> allow us to do is to distinguish between value and reference types for
> generics. I tried this differentiation types with protocols like
> `AnyReference` and `AnyValue` in another topic before (Should we rename
> "class" when referring to protocol conformance?
> ),
> but I kinda like this new approach.
>
> Here is what I mean in detail:
>
> protocol SomeProtocol /* we can’t constraint it to value types at the
> moment, only `class`es works */ {}
>
> func foo(value: struct) { /* do some work */ }
>
> This function is pretty neat. (1) You can force the library user to create
> a struct with conformance to `SomeProtocol`. (2) This approach will accept
> any struct which conforms to that protocol.
>
> As I said in the protocol comment above protocols can only be constrained
> to classes at the moment, and this might change in the future. If we also
> had some sort of things for generics so the function from above might have
> looked like this:
>
> func foo(value: T) {}
>
> But it seems that such a thing won’t ever happen to Swift.
>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for us.
> `all<>` would accept any type at its first element.
>
> func foo(value: all)
> { /* T could be a reference type or value type */ }
>
> That been said, `all<>` could replace `protocol<>` where it is composed
> from protocols. `all<>` can only be used as a generic constraints if the
> first element is a protocol or a reference type.
>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?
>
>
> No.  These say nothing about semantics.  PureValue is all about the
> semantics of a type and has nothing to do with what mechanism is used to
> implement the type.
>
>
> struct A {
>
> var value: struct // if we drop the strict rule of at least one
> protocols
> }
>
> How does it sound to you?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (sva...@gmail.com) schrieb:
>
> 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()
> }
>
> public protocol 

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

[Adrian Zubarev via swift-evolution]

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, because this is what we are interested in, but 
I provided all possible combinations if the other formats would exists (at 
least all combinations I could think of, anything else is derived from these). 

`class<>` etc. can be seen as a future direction (I would say), otherwise this 
would easily become out of scope for Swift 3. (I will  move `class<>` etc. from 
detailed design to future direction later.)

I’d love to hear your feedback and strong arguments for the motivation part I 
could include into this proposal.

-- 
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 23:16:20, Vladimir.S (sva...@gmail.com) schrieb:

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 will be introduced in Swift ;-)  

On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:  
> Can we really do that? I mean, I thought about that myself but I came to  
> the conclusion that this scenario is like: I was to lazy to couple this  
> structs to my library protocols, will you do that for me?  
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 will be introduced in Swift ;-)


On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:

Can we really do that? I mean, I thought about that myself but I came to
the conclusion that this scenario is like: I was to lazy to couple this
structs to my library protocols, will you do that for me?

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

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

[Adrian Zubarev via swift-evolution]

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 like: I was to lazy to couple this structs to 
my library protocols, will you do that for me?

Sure one could think that this protocols might be optional but the `f(p: 
MyProtocol)` function will cover this scenario.

Another interesting side-effect `struct<>`, `class<>` and `enum<>` will allow 
us to do is to distinguish between value and reference types for generics. I 
tried this differentiation types with protocols like `AnyReference` and 
`AnyValue` in another topic before (Should we rename "class" when referring to 
protocol conformance?), but I kinda like this new approach.

Here is what I mean in detail:

protocol SomeProtocol /* we can’t constraint it to value types at the moment, 
only `class`es works */ {}

func foo(value: struct) { /* do some work */ }

This function is pretty neat. (1) You can force the library user to create a 
struct with conformance to `SomeProtocol`. (2) This approach will accept any 
struct which conforms to that protocol.

As I said in the protocol comment above protocols can only be constrained to 
classes at the moment, and this might change in the future. If we also had some 
sort of things for generics so the function from above might have looked like 
this:

func foo(value: T) {}

But it seems that such a thing won’t ever happen to Swift.

Basically `struct<>`, `class<>` and `enum<>` will just enable this for us. 
`all<>` would accept any type at its first element.

func foo(value: all) { /* 
T could be a reference type or value type */ }

That been said, `all<>` could replace `protocol<>` where it is composed from 
protocols. `all<>` can only be used as a generic constraints if the first 
element is a protocol or a reference type.

@Matthew: isn’t this somehow a step towards (generic) `PureValue` types?

struct A {

    var value: struct // if we drop the strict rule of at least one protocols
}

How does it sound to you?
 
-- 
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 20:34:59, Vladimir.S (sva...@gmail.com) schrieb:

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()  
}  

public protocol ExtraProtocol2 {  
func blort()  
}  

then we actually can have such code:  

func f(p: MyProtocol) {  
if let a = p as? struct {  
a.foo()  
a.bar()  
}  
else  
if let b = p as? struct {  
b.foo()  
b.blort()  
}  
}  




On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:  
>> '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 { /* do  
>> something with a */ }  
>>  
>> else if let b = value as? struct { /* do  
>> something with b */ }  
>>  
>> }  
>>  
>> In this scenario you’ll be able to access properties and functions  
>> from `StructA` or `StructB` which might not be covered by  
>> `SomeProtocol`. Everything is merged nicely into one instance. But  
>> you are right it depends on the use-case.  
>>  
>>  
>> There is no need to include the protocol here. Just do this:  
>>  
>> if let a = value as? StructA { use a }  
>>  
> Whoops, I forgot that this will do the trick. I apologize for any confusion  
> here, you are totally right.  
>  
> That been said, do we really need `type<>` aka. `all<>` for value types? I  
> need to rethink this part of the proposal. Is there any use-case where we  
> would need this (any scenario for the future Swift version also counts)?  
>  
> If we had `all<>` in Swift already for extendable reference types and one  
> day structs would become subtypeable, this wouldn’t be a huge problem to  
> upgrade `all<>` for structs I guess.  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
>  
>  
> ___  
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S via swift-evolution]

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()
}

public protocol ExtraProtocol2 {
  func blort()
}

then we actually can have such code:

func f(p: MyProtocol) {
  if let a = p as? struct {
 a.foo()
 a.bar()
  }
  else
  if let b = p as? struct {
 b.foo()
 b.blort()
  }
}

as we can(as example) expect that in 3rd party code someone will do:

extension StructA: ExtraProtocol1 {
  func bar() {}
}

extension StructB: ExtraProtocol2 {
  func blort() {}
}



On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:

'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 { /* do
something with a */ }

else if let b = value as? struct { /* do
something with b */ }

}

In this scenario you’ll be able to access properties and functions
from `StructA` or `StructB` which might not be covered by
`SomeProtocol`. Everything is merged nicely into one instance. But
you are right it depends on the use-case.


There is no need to include the protocol here.   Just do this:

if let a = value as? StructA { use a }


Whoops, I forgot that this will do the trick. I apologize for any confusion
here, you are totally right.

That been said, do we really need `type<>` aka. `all<>` for value types? I
need to rethink this part of the proposal. Is there any use-case where we
would need this (any scenario for the future Swift version also counts)?

If we had `all<>` in Swift already for extendable reference types and one
day structs would become subtypeable, this wouldn’t be a huge problem to
upgrade `all<>` for structs I guess.

--
Adrian Zubarev
Sent with Airmail



___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

'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 { /* do something with a 
*/ }

    else if let b = value as? struct { /* do something 
with b */ }

}

In this scenario you’ll be able to access properties and functions from 
`StructA` or `StructB` which might not be covered by `SomeProtocol`. Everything 
is merged nicely into one instance. But you are right it depends on the 
use-case.


There is no need to include the protocol here.   Just do this:

if let a = value as? StructA { use a }

Whoops, I forgot that this will do the trick. I apologize for any confusion 
here, you are totally right.

That been said, do we really need `type<>` aka. `all<>` for value types? I need 
to rethink this part of the proposal. Is there any use-case where we would need 
this (any scenario for the future Swift version also counts)?

If we had `all<>` in Swift already for extendable reference types and one day 
structs would become subtypeable, this wouldn’t be a huge problem to upgrade 
`all<>` for structs I guess.

-- 
Adrian Zubarev
Sent with Airmail

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

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

[Adrian Zubarev via swift-evolution]

'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 { /* do something with a 
*/ }

    else if let b = value as? struct { /* do something 
with b */ }

}

In this scenario you’ll be able to access properties and functions from 
`StructA` or `StructB` which might not be covered by `SomeProtocol`. Everything 
is merged nicely into one instance. But you are right it depends on the 
use-case.



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

True, I didn’t thought about that effect at the first glance, thank you for the 
hint. I will add this to the draft proposal tomorrow.


-- 
Adrian Zubarev
Sent with Airmail

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

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

[Vladimir.S via swift-evolution]

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 19:38, Adrian Zubarev via swift-evolution wrote:

Why would you want to add all of these different formats where only one
could serve them all. This is redundant in my opinion.

`struct<>` and `enum<>` would have same rules, only the first element would
be a different value-type. I might consider this as an alternative.



Actually, I fully support your idea and strongly +1 for `type<>` keyword. I
don't believe it will confuse anyone as protocol<> does not confuse currently.

But as I can see, the community(or core team) is strongly against of using
`type` keyword.
So, we have situation : protocol<> and .. all<> ? Will all<> include
protocols also? Probably I'd support to remove protocol<> and introduce
just all<> for all :-) But if we have protocol<> and can't have type<> - I
asked why we can't for clarity and consistency have class<> struct<>

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

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

[Adrian Zubarev via swift-evolution]

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 struct
Why would you want to add all of these different formats where only one could 
serve them all. This is redundant in my opinion. 

`struct<>` and `enum<>` would have same rules, only the first element would be 
a different value-type. I might consider this as an alternative.

Correct me if I’m wrong with the redundancy.

———

The & type operator would produce a “flattened" all<> with its operands.  It 
could be overloaded to accept either a concrete type or a protocol on the lhs 
and would produce `type` for an lhs that is a type and `all` when lhs is a 
protocol.   "Type operators” would be evaluated during compile time and would 
produce a type that is used where the expression was present in the code.  This 
is a long-term idea, not something that needs to be considered right now.  It 
would be way out of scope for Swift 3.  
Which part of your statement is exactly out of scope for Swift 3, “Type 
operators“ I guess? 

So is it a good idea to add `&` operator for "flattened“ `all<>` whereas “Type 
operators“ would be a better way to go (for Swift 4 maybe)? As far as I 
understand the idea behind `&` operator I’m not sure how it could be 
overloaded, because I thought it would be baked right into the language.

If I mixed something up here please feel free to correct me.

———

Would you mind to give me some feedback for the rules I've summarized.

———

The overall feedback seems to be positive so for and my fingers are crossed for 
this feature to be accepted.

-- 
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 08:16:51, Thorsten Seitz (tseit...@icloud.com) schrieb:



Am 12. Mai 2016 um 22:08 schrieb Adrian Zubarev via swift-evolution 
:

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

`all<>` and `any<>` form a pair of complementary type operators, one creating 
the intersection of the given types (your proposal) and the other creating the 
union of the given types. As Ceylon has demonstrated that both are really 
useful I'd like to have both in Swift and therefore would prefer that both 
should be named such that this duality is visible. Having `type<>` and `any<>` 
would certainly be possible technically but the naming would not be good.


>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 
>`type<>`. Or can we refine the rules of `type<>` to get to `any<>`?

You are right, `any<>` is something different and could be proposed in its own 
thread. I just wanted to extend the context for finding a good name for 
`type<>`.


Here is a little example where `any<>` gets strange:

func foo(value: any) -> any {

    // how would one use value here?
    // what about its properties
    // what will foo return and how to use the result
}

Ceylon uses flow typing for that (if (is String value) { /* value has type 
String here */ }).
In Swift the equivalent would be `if let string = value as? String { ... }`:

func foo(value: any) -> any {
   if let string = value as? String {
  return string.characters.count
   }
   else if let int= value as? Int {
  return String(int)
   }
}

A more sensical example using a type union would be the union of two sets:

func union(a: Set, b: Set) -> Set> { ... }

And for type intersection the intersection of two sets:

func intersection(a: Set, b: Set) -> Set> { ... }

(Ceylon's type operators just read better there...)

Another example for type unions:
Ceylon like Swift makes heavy use of optionals but where Swift has a generic 
wrapper Optional Ceylon just makes use of type unions: in Ceylon T? is 
syntactic sugar for the type union T | Null where Null is the type having the 
singleton value null.

FWIW Microsoft's Typescript gained union and intersection types about (I think) 
a year ago.


One benefit of `any<>` is the replacement of overloading, at least for the type 
part of the function.

Exactly.

 
`all<>` could be seen as an alternative name for `type<>`, but to me its not 
clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.

Right, `all<>` is just an alternative name for `type<>`. There is no change in 
functionality.

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

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

[Matthew Johnson via swift-evolution]

> 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 type composition.  
> 
> Would you mind to provide a more detailed design from your perspective? I 
> mean, how do you imagine `type<>` aka. `all<>` to look like with operators?
> 
> 

The & type operator would produce a “flattened" all<> with its operands.  It 
could be overloaded to accept either a concrete type or a protocol on the lhs 
and would produce `type` for an lhs that is a type and `all` when lhs is a 
protocol.   "Type operators” would be evaluated during compile time and would 
produce a type that is used where the expression was present in the code.  This 
is a long-term idea, not something that needs to be considered right now.  It 
would be way out of scope for Swift 3.  


> Any feedback is welcome. :)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 17:05:29, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> 
>> 
>> 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 `protocol` might look nice, and then extend that to 
>>> allow concrete types as well. Then, if Swift ever decided to support union 
>>> types, the `|` operator naturally fits there.
>> 
>> +1
>> 
>> 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 type composition.  
>> 
>>> 
>>> One concern though would be whether parsing would get more complicated with 
>>> deeply composed expressions. If we only supported `&`, there's no real 
>>> nesting going on. But if we wanted to be forward thinking and leave the 
>>> door open for `|`, we might need to support things like `(String | Int) & 
>>> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
>>> would really complicate things (e.g., could the compiler decide easily 
>>> enough that those parentheses are part of a type expression and not a 
>>> function type?).
>>> 
>>> `all` would be a nice compromise in that case, and leave the door 
>>> open for `any` in the future. So I'd be supportive of either option.
>> 
>> This makes sense as an immediate step in the right direction.  I like that 
>> it is more concise than protocol<>
>>> 
>>> 
>>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>>> > wrote:
>>> 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.
>>> 
>>> I will say that "type" is unlikely to see much traction simply because it 
>>> is an incredibly common name for both properties and locals. We went 
>>> through that exercise when trying to name both "static" and "dynamicType" 
>>> and decided that it would be too confusing, even if we could make the 
>>> parsing work.
>>> 
>>> The feature itself has definitely been shown to be useful when working with 
>>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>>> have it internally tracked in Radar as rdar://problem/15873071 <>.
>>> 
>>> Jordan
>>> 
>>> 
 On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
 > wrote:
 
 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 `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
 
 Here is a little example where `any<>` gets strange:
 
 func foo(value: any) -> any {
 
 // how would one use value here?
 // what about its properties
 // what will foo return and how to use the result
 }
 
 One benefit of `any<>` is the replacement of overloading, at least for the 
 type part of the function.
 
 I’d like to propose `type<>` as the base extension to the language in that 
 direction, before we’ll move forward with more complex scenarios (just 
 like Chris did with generic 

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

[Vladimir.S via swift-evolution]

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

Like
func f(obj: class) {..}
if obj is class {..}
obj2 = obj as! class

and yes, probably struct


On 13.05.2016 17:21, 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 `protocol` might look nice, and then extend that to
allow concrete types as well. Then, if Swift ever decided to support union
types, the `|` operator naturally fits there.

One concern though would be whether parsing would get more complicated with
deeply composed expressions. If we only supported `&`, there's no real
nesting going on. But if we wanted to be forward thinking and leave the
door open for `|`, we might need to support things like `(String | Int) &
SomeProtocol`, and I'm not enough of a parser expert to know whether that
would really complicate things (e.g., could the compiler decide easily
enough that those parentheses are part of a type expression and not a
function type?).

`all` would be a nice compromise in that case, and leave the door
open for `any` in the future. So I'd be supportive of either option.


On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution
> wrote:

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.

I will say that "type" is unlikely to see much traction simply because
it is an /incredibly/ common name for both properties and locals. We
went through that exercise when trying to name both "static" and
"dynamicType" and decided that it would be too confusing, even if we
could make the parsing work.

The feature itself has definitely been shown to be useful when working
with the Cocoa frameworks, if not in general. I don't see it on JIRA
yet but we have it internally tracked in Radar as rdar://problem/15873071.

Jordan



On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution
> wrote:

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 `type<>`. Or can we refine the rules of `type<>` to
get to `any<>`?

Here is a little example where `any<>` gets strange:

func foo(value: any) -> any {

// how would one use value here?
// what about its properties
// what will foo return and how to use the result
}

One benefit of `any<>` is the replacement of overloading, at least
for the type part of the function.

I’d like to propose `type<>` as the base extension to the language in
that direction, before we’ll move forward with more complex scenarios
(just like Chris did with generic typealias).

This function is clear that it only will work if you provide a
subclass of an UIView which conforms to SomeProtocol (nice addition
for library design).

func foo(value: type) ->
type {

// use it as a UIView and SomeProtocol at the same type
return value // return type works great
}

We can split the value just fine:

let mergedValue = foo(SomeViewThatWorks)
let view: UIView = mergedValue
let protocolValue: SomeProtocol = mergedValue

And merge it back together:

guard let newMergedValue = view as? type else {
/* do something */ }

`all<>` could be seen as an alternative name for `type<>`, but to me
its not clear what `all<>` can do, whereas `type<>` is almost like
`protocol<>`.

--
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com
) schrieb:


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

type

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

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

Is the name `type<>` really that bad for the compiler?

Here I’m not sure, because that is out of my experience. From a readers 
perspective it’s more clear than `all<>`, I would say, even though this is a 
perfect explanation why it should be called `all<>`:

I also see Thorsten (and in the past Brent's?) argument for calling it "all" or 
"All", because it's enforcing multiple constraints.
Do we miss any rules here?

`type<>` can contain only one value-type or reference-type and n protocols
the value-type or reference-type should always be the first element between 
angle brackets
`type<>` should always contain at least 2 types (one value-type or a 
reference-type and at least one protocol)
reference-types do represent a possible super/base type/class
nesting `type<>` is not allowed, however `type<>` can contain `protocol<>`
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?)
Does this proposal need more than the base `type<>`?

Maybe, but I think we should start with `type<>` before we will introduce a 
type operator for this.

Did I missed anything out here? 

PS: Feel free to help me with my English, because it’s not so well.

-- 
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com) schrieb:

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 `|` operator 
naturally fits there.

One concern though would be whether parsing would get more complicated with 
deeply composed expressions. If we only supported `&`, there's no real nesting 
going on. But if we wanted to be forward thinking and leave the door open for 
`|`, we might need to support things like `(String | Int) & SomeProtocol`, and 
I'm not enough of a parser expert to know whether that would really complicate 
things (e.g., could the compiler decide easily enough that those parentheses 
are part of a type expression and not a function type?).

`all` would be a nice compromise in that case, and leave the door open 
for `any` in the future. So I'd be supportive of either option.


On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
 wrote:
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.

I will say that "type" is unlikely to see much traction simply because it is an 
incredibly common name for both properties and locals. We went through that 
exercise when trying to name both "static" and "dynamicType" and decided that 
it would be too confusing, even if we could make the parsing work.

The feature itself has definitely been shown to be useful when working with the 
Cocoa frameworks, if not in general. I don't see it on JIRA yet but we have it 
internally tracked in Radar as rdar://problem/15873071.

Jordan


On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
 wrote:

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 
>`type<>`. Or can we refine the rules of `type<>` to get to `any<>`?

Here is a little example where `any<>` gets strange:

func foo(value: any) -> any {

    // how would one use value here?
    // what about its properties
    // what will foo return and how to use the result
}

One benefit of `any<>` is the replacement of overloading, at least for the type 
part of the function.

I’d like to propose `type<>` as the base extension to the language in that 
direction, before we’ll move forward with more complex scenarios (just like 
Chris did with generic typealias).

This function is clear that it only will work if you provide a subclass of an 
UIView which conforms to SomeProtocol (nice addition for library design).

func foo(value: type) -> type {

    // use it as a UIView and SomeProtocol at the same type
    return value // return type works great
}

We can split the value just fine:

let mergedValue = foo(SomeViewThatWorks)
let view: UIView = mergedValue
let protocolValue: SomeProtocol = 

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

[Matthew Johnson via swift-evolution]

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 `protocol` might look nice, and then extend that to 
> allow concrete types as well. Then, if Swift ever decided to support union 
> types, the `|` operator naturally fits there.

+1

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

> 
> One concern though would be whether parsing would get more complicated with 
> deeply composed expressions. If we only supported `&`, there's no real 
> nesting going on. But if we wanted to be forward thinking and leave the door 
> open for `|`, we might need to support things like `(String | Int) & 
> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
> would really complicate things (e.g., could the compiler decide easily enough 
> that those parentheses are part of a type expression and not a function 
> type?).
> 
> `all` would be a nice compromise in that case, and leave the door open 
> for `any` in the future. So I'd be supportive of either option.

This makes sense as an immediate step in the right direction.  I like that it 
is more concise than protocol<>
> 
> 
>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>>  wrote:
>> 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.
>> 
>> I will say that "type" is unlikely to see much traction simply because it is 
>> an incredibly common name for both properties and locals. We went through 
>> that exercise when trying to name both "static" and "dynamicType" and 
>> decided that it would be too confusing, even if we could make the parsing 
>> work.
>> 
>> The feature itself has definitely been shown to be useful when working with 
>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>> have it internally tracked in Radar as rdar://problem/15873071.
>> 
>> Jordan
>> 
>> 
>>> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> 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 `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
>>> 
>>> Here is a little example where `any<>` gets strange:
>>> 
>>> func foo(value: any) -> any {
>>> 
>>> // how would one use value here?
>>> // what about its properties
>>> // what will foo return and how to use the result
>>> }
>>> 
>>> One benefit of `any<>` is the replacement of overloading, at least for the 
>>> type part of the function.
>>> 
>>> I’d like to propose `type<>` as the base extension to the language in that 
>>> direction, before we’ll move forward with more complex scenarios (just like 
>>> Chris did with generic typealias).
>>> 
>>> This function is clear that it only will work if you provide a subclass of 
>>> an UIView which conforms to SomeProtocol (nice addition for library design).
>>> 
>>> func foo(value: type) -> type {
>>> 
>>> // use it as a UIView and SomeProtocol at the same type
>>> return value // return type works great
>>> }
>>> 
>>> We can split the value just fine:
>>> 
>>> let mergedValue = foo(SomeViewThatWorks)
>>> let view: UIView = mergedValue
>>> let protocolValue: SomeProtocol = mergedValue
>>> 
>>> And merge it back together:
>>> 
>>> guard let newMergedValue = view as? type else { /* do 
>>> something */ }
>>> 
>>> `all<>` could be seen as an alternative name for `type<>`, but to me its 
>>> not clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com) schrieb:
>>> 
 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
 
 type 
 
 is much nicer than protocol<> for 

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

[Tony Allevato via swift-evolution]

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 `|` operator naturally fits there.

One concern though would be whether parsing would get more complicated with
deeply composed expressions. If we only supported `&`, there's no real
nesting going on. But if we wanted to be forward thinking and leave the
door open for `|`, we might need to support things like `(String | Int) &
SomeProtocol`, and I'm not enough of a parser expert to know whether that
would really complicate things (e.g., could the compiler decide easily
enough that those parentheses are part of a type expression and not a
function type?).

`all` would be a nice compromise in that case, and leave the door
open for `any` in the future. So I'd be supportive of either option.


On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> 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.
>
> I will say that "type" is unlikely to see much traction simply because it
> is an *incredibly* common name for both properties and locals. We went
> through that exercise when trying to name both "static" and "dynamicType"
> and decided that it would be too confusing, even if we could make the
> parsing work.
>
> The feature itself has definitely been shown to be useful when working
> with the Cocoa frameworks, if not in general. I don't see it on JIRA yet
> but we have it internally tracked in Radar as rdar://problem/15873071.
>
> Jordan
>
>
> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
>
> Here is a little example where `any<>` gets strange:
>
> func foo(value: any) -> any {
>
> // how would one use value here?
> // what about its properties
> // what will foo return and how to use the result
> }
>
> One benefit of `any<>` is the replacement of overloading, at least for the
> type part of the function.
>
> I’d like to propose `type<>` as the base extension to the language in that
> direction, before we’ll move forward with more complex scenarios (just like
> Chris did with generic typealias).
>
> This function is clear that it only will work if you provide a subclass of
> an UIView which conforms to SomeProtocol (nice addition for library design).
>
> func foo(value: type) -> type {
>
> // use it as a UIView and SomeProtocol at the same type
> return value // return type works great
> }
>
> We can split the value just fine:
>
> let mergedValue = foo(SomeViewThatWorks)
> let view: UIView = mergedValue
> let protocolValue: SomeProtocol = mergedValue
>
> And merge it back together:
>
> guard let newMergedValue = view as? type else { /*
> do something */ }
>
> `all<>` could be seen as an alternative name for `type<>`, but to me its
> not clear what `all<>` can do, whereas `type<>` is almost like
> `protocol<>`.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com)
> schrieb:
>
> 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
>
> type
>
> is much nicer than protocol<> for intersection types but to keep the door
> open for union types, I would prefer
>
> all
>
> This would allow
>
> any
>
> to be used for union types.
>
> -Thorsten
>
>
> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>
> 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 love to discuss if there might be any disadvantages to this
> feature.
>
> --
> Adrian Zubarev
> Sent 

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

[Jordan Rose via swift-evolution]

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.

I will say that "type" is unlikely to see much traction simply because it is an 
incredibly common name for both properties and locals. We went through that 
exercise when trying to name both "static" and "dynamicType" and decided that 
it would be too confusing, even if we could make the parsing work.

The feature itself has definitely been shown to be useful when working with the 
Cocoa frameworks, if not in general. I don't see it on JIRA yet but we have it 
internally tracked in Radar as rdar://problem/15873071 
.

Jordan


> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 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 
> `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
> 
> Here is a little example where `any<>` gets strange:
> 
> func foo(value: any) -> any {
> 
> // how would one use value here?
> // what about its properties
> // what will foo return and how to use the result
> }
> 
> One benefit of `any<>` is the replacement of overloading, at least for the 
> type part of the function.
> 
> I’d like to propose `type<>` as the base extension to the language in that 
> direction, before we’ll move forward with more complex scenarios (just like 
> Chris did with generic typealias).
> 
> This function is clear that it only will work if you provide a subclass of an 
> UIView which conforms to SomeProtocol (nice addition for library design).
> 
> func foo(value: type) -> type {
> 
> // use it as a UIView and SomeProtocol at the same type
> return value // return type works great
> }
> 
> We can split the value just fine:
> 
> let mergedValue = foo(SomeViewThatWorks)
> let view: UIView = mergedValue
> let protocolValue: SomeProtocol = mergedValue
> 
> And merge it back together:
> 
> guard let newMergedValue = view as? type else { /* do 
> something */ }
> 
> `all<>` could be seen as an alternative name for `type<>`, but to me its not 
> clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com 
> ) schrieb:
> 
>> 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
>> 
>> type 
>> 
>> is much nicer than protocol<> for intersection types but to keep the door 
>> open for union types, I would prefer
>> 
>> all
>> 
>> This would allow
>> 
>> any
>> 
>> to be used for union types.
>> 
>> -Thorsten
>> 
>> 
>>> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
>>> >:
>>> 
>>> 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 love to discuss if there might be any disadvantages to this 
>>> feature.
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com 
>>> ) schrieb:
>>> 
 protocol<> 
>>> ___
>>> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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 
>`type<>`. Or can we refine the rules of `type<>` to get to `any<>`?

Here is a little example where `any<>` gets strange:

func foo(value: any) -> any {

    // how would one use value here?
    // what about its properties
    // what will foo return and how to use the result
}

One benefit of `any<>` is the replacement of overloading, at least for the type 
part of the function.

I’d like to propose `type<>` as the base extension to the language in that 
direction, before we’ll move forward with more complex scenarios (just like 
Chris did with generic typealias).

This function is clear that it only will work if you provide a subclass of an 
UIView which conforms to SomeProtocol (nice addition for library design).

func foo(value: type) -> type {

    // use it as a UIView and SomeProtocol at the same type
    return value // return type works great
}

We can split the value just fine:

let mergedValue = foo(SomeViewThatWorks)
let view: UIView = mergedValue
let protocolValue: SomeProtocol = mergedValue

And merge it back together:

guard let newMergedValue = view as? type else { /* do 
something */ }

`all<>` could be seen as an alternative name for `type<>`, but to me its not 
clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com) schrieb:

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

type 

is much nicer than protocol<> for intersection types but to keep the door open 
for union types, I would prefer

all

This would allow

any

to be used for union types.

-Thorsten


Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
:

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 love to discuss if there might be any disadvantages to this 
feature.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:

protocol<> 
___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

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

type 

is much nicer than protocol<> for intersection types but to keep the door open 
for union types, I would prefer

all

This would allow

any

to be used for union types.

-Thorsten


> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> 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 love to discuss if there might be any disadvantages to this 
> feature.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com 
> ) schrieb:
> 
>> protocol<> 
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Tony Allevato via swift-evolution]

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 had to explicitly use id instead of a stronger
class-based type simply to ensure Swift interoperability.

The other option of course is to import those things as generic functions
with constraints, but (1) that doesn't solve it for properties, and (2) if
we already support composing protocols in this way, why not also allow it
for other types, where it can be used for properties and variables? This
approach feels like it would round out the type system nicely.


On Thu, May 12, 2016 at 7:09 AM Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 love to discuss if there might be any disadvantages to this
> feature.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:
>
> protocol<>
>
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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 love to discuss if there might be any disadvantages to this 
feature.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:

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

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

[Vladimir.S via swift-evolution]

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 protocol?
So, if this feature could be implemented, I'm +1 on this `type<>` feature
Or probably we can allow class in protocol<>

On 11.05.2016 21:06, Adrian Zubarev via swift-evolution wrote:

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.

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 types which conforms to specific protocols (if there is a need).

protocol SomeProtocol {
func boo()
}

// this use-case can be solved with generic typealias in Swift 3 (at
least for classes), but it is not the only one usecase of type merging
func foo(mergedInstance: type) {
mergedInstance.removeFromSuperview() // just for the example
mergedInstance.boo()
}

extension UIButton: SomeProtocol { /* implemnt boo() */ }

let button: SomeProtocol = UIButton() // decouple UIButton first

Ok now I want to use one instance as SomeProtocol and UIView.

// another possible use-case
if let mergedView = button as? type {
mergedView.removeFromSuperview() // just for the example
mergedView.boo()
}

More detailed design:

- type<> can contain only one value or reference type and n protocols
- value or reference type should always be the first type
- type<> should always contain at least 2 types (one value or reference
type and min. one protocol)
- reference types does represent one possible super/base type of the
actuall type
 * class A {}
 * class B: A {}
 * class C: B {}
 * possible types for B and C: type or
type
- the dynamicType/Self instance passed to type<> conforms to all
protocols type<> contains

If there is more rules one would apply to this idea feel free to discuss
them here.

--
Adrian Zubarev
Sent with Airmail



___
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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

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.

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 types which conforms to specific protocols (if there is a need).

protocol SomeProtocol {
func boo()
}

// this use-case can be solved with generic typealias in Swift 3 (at least for 
classes), but it is not the only one usecase of type merging
func foo(mergedInstance: type) {
mergedInstance.removeFromSuperview() // just for the example
mergedInstance.boo()
}

extension UIButton: SomeProtocol { /* implemnt boo() */ }

let button: SomeProtocol = UIButton() // decouple UIButton first

Ok now I want to use one instance as SomeProtocol and UIView.

// another possible use-case
if let mergedView = button as? type {
mergedView.removeFromSuperview() // just for the example
mergedView.boo()
}

More detailed design:

- type<> can contain only one value or reference type and n protocols
- value or reference type should always be the first type
- type<> should always contain at least 2 types (one value or reference type 
and min. one protocol)
- reference types does represent one possible super/base type of the actuall 
type 
     * class A {}
     * class B: A {}
     * class C: B {}
     * possible types for B and C: type or type
- the dynamicType/Self instance passed to type<> conforms to all protocols 
type<> contains

If there is more rules one would apply to this idea feel free to discuss them 
here.

-- 
Adrian Zubarev
Sent with Airmail___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution