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

But don't you mean the union type of all possible Collection types when you write Any<Collection>?

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<class>`, and things like `Any<Collection>` 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:

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&B&C) {..}
> if obj is A&B&C {...}
> obj2 = obj as! A&B&C
>
> (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

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<A, B> 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<A, B> in Swift.

-Thorsten

···

Am 14.05.2016 um 20:08 schrieb Thorsten Seitz via swift-evolution <swift-evolution@swift.org>:

-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 (allevato@google.com <mailto:allevato@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<A, B>` 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<A, B>` would be a nice compromise in that case, and leave the door open for `any<A, B>` 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 <mailto: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 <mailto: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<String, Int>) -> any<String, Int> {

    // 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<UIView, SomeProtocol>) -> type<UIView, SomeProtocol> {

    // 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<UIView, SomeProtocol> 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 (tseitz42@icloud.com <mailto:tseitz42@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<SomeRealClass, SomeProtocol>

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

all<SomeRealClass, SomeProtocol>

This would allow

any<String, Int>

to be used for union types.

-Thorsten

Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

protocol<SomeRealClass, SomeProtocol>
protocol<SomeRealStruct, SomeProtocol>

This feels really odd to me.

`type<SomeRealClass, SomeProtocol>` 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 (svabox@gmail.com <mailto:svabox@gmail.com>) schrieb:

protocol<>

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

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

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/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<T, U>(set1: Set<T>, set2: Set<U>) -> Set<All<T, U>>

If T == U we'll get All<T, T> == T

Or simply:

func intersect<T>(set1: Set<T>, set2: Set<T>) -> Set<All<T>>

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 <swift-evolution@swift.org> wrote:
>
> > But don't you mean the union type of all possible Collection types when you write Any<Collection>?
>
> No, I mean "an existential capable of holding any Collection".
>
> If I write Any<Equatable, Collection>, I mean "an existential capable of holding any Equatable Collection".
>
> If I write Any<UITableViewCell, CounterDisplaying>, I mean "an existential capable of holding any CounterDisplaying UITableViewCell".
>
> If I write Any<Collection where .Element: Equatable>, I mean "an existential capable of holding any Collection with an Equatable Element".
>
> If I write Any<class>, 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

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/nnnn-mechanism-to-combine-types-and-protocols.md

···

--
Adrian Zubarev
Sent with Airmail

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

Sent from my iPad

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

But don't you mean the union type of all possible Collection types when you write Any<Collection>?

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<class>`, and things like `Any<Collection>` 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

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

···

On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 15:34:10, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

Sent from my iPad

On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

But don't you mean the union type of all possible Collection types when you write Any<Collection>?

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<class>`, and things like `Any<Collection>` 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 <mailto:swift-evolution@swift.org>) schrieb:

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/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<Collection where Element == String>`? 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

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

···

On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> 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<Collection where Element == String>`? I’m not sure where I should consider such a scenario, maybe at future directions?

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.

Austin

···

On Tue, May 17, 2016 at 11:02 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

On May 17, 2016, at 10:40 AM, Adrian Zubarev < > adrian.zubarev@devandartist.com> 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<Collection where Element == String>`? 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

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

···

Sent from my iPad

On May 17, 2016, at 1:11 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

Austin

On Tue, May 17, 2016 at 11:02 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> 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<Collection where Element == String>`? 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

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<Collection where Element == String>`? 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?

···

Sent from my iPad

On May 17, 2016, at 1:02 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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 (dgregor@apple.com) schrieb:

On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> 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<Collection where Element == String>`? 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

Regards
(From mobile)

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<Collection where Element == String>`? I’m not sure where I should consider such a scenario, maybe at future directions?

Very reminiscent of xpath...

Any<Collection[@Element == String]>

a lot more concise though

···

On May 17, 2016, at 7:40 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

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

Ok I feel like I’m ready to submit this `base` proposal for `Any<>` which can be extended even further later on.

Please take a last look: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-mechanism-to-combine-types-and-protocols.md

···

--
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 20:18:55, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

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 (dgregor@apple.com) schrieb:

On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> 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<Collection where Element == String>`? 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

Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here:

@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

It looks good. I'll probably read it more thoroughly later and comment if
necessary. Thanks for putting it together!

If this is accepted I'll revise my other proposal to remove the
class-related stuff, and everything that previous proposals have already
covered.

Austin

···

On Sat, May 21, 2016 at 5:42 AM, Adrian Zubarev < adrian.zubarev@devandartist.com> 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/nnnn-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

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 <swift-evolution@swift.org> 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/nnnn-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

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<class> {} as replacement.

···

--
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matthew@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 <swift-evolution@swift.org> wrote:

Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here:

@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

Fixed a few things: swift-evolution/nnnn-classes-in-any-existential.md at classes_in_any_existential · DevAndArtist/swift-evolution · GitHub

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.zubarev@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<class> {} as replacement.

--
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matthew@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 <swift-evolution@swift.org> wrote:

Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here:

@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

Bikeshedding: Is it grammatically possible (or even desirable) to skip the “any” token and just have something like this:

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

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

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

Fixed a few things: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/nnnn-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.zubarev@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<class> {} as replacement.

--
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matthew@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 <swift-evolution@swift.org> 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/nnnn-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