> On May 18, 2016, at 3:15 PM, Adrian Zubarev via swift-evolution
> <[email protected]> wrote:
>
> So without any initial constraints how would one use this generic function??
>
> extension UIButton: ProtocolA {}
>
> let button = UIButton()
> let shadowedButton: ProtocolA = UIButton()
>
> // creates a set of a least one element if the generic type could be inferred
> func unionIfPossible<T, U>(_ a: T, _ b: U) -> Set<Any<T, U>>? { /* merge
> somehow if possible */ }
You would not be able to form Any<T, U> here because T and U are generic
arguments unknown. We don’t accept those, only `class`, specific classes, and
specific protocols (and recursively, other Any).
>
> // this should be valid because the compiler will assume Any<UIView,
> ProtocolA> where T == UIView and U == ProtocolA
> let merged_1: Set<Any<UIView, ProtocolA>> = unionIfPossible( /* UIView
> subtype */ button, /* ProtocolA */ shadowedButton)
>
> // this won’t be possible because of the restriction
> let merged_2: Set<Any<UIView, ProtocolA>> = unionIfPossible(shadowedButton,
> button)
>
> Any<UIView, ProtocolA> != Any<ProtocolA, UIView> isn’t right. Sure it may
> feel right for readability but the types should be equal.
>
> "Can be any class type that is a UIView or a subclass of UIView, that also
> conforms to ProtocolA.“ == "Type that conforms to ProtocolA and that is a
> UIView or a subclass of UIView.“
>
> This is also a nesting problem where you will be forced to choose the right
> place inside the angle brackets where to add a nested `Any<…>`.
>
> class A: ClassB, ProtocolA {}
>
> Any<A, Any<ClassB, ProtocolA>> == A != Any<Any<ClassB, ProtocolA>, A> ==
> Any<ClassB, ProtocolA, A> which should be reorder by the compiler and
> inferred as A
`Any<Any<ClassB, ProtocolA>, A>` is not allowed because if a class is provided
it must come first.
`Any<ClassB, ProtocolA, A>` is not allowed because it contains more than one
class.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 18. Mai 2016 bei 21:23:35, Austin Zheng ([email protected]
> <mailto:[email protected]>) schrieb:
>
>> I strongly prefer keeping the class requirement first, both for readability
>> and because this reflects how protocol and 'class' or superclass
>> conformances already work when defining classes or protocols. I think "look
>> at the first argument, and then recursively look at the first arguments of
>> any nested Any's for class requirements" is straightforward enough not to
>> confuse people, and helps keep the type definitions organized.
>>
>> Austin
>>
>> On Wed, May 18, 2016 at 12:11 PM, Matthew Johnson via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On May 18, 2016, at 12:12 PM, Adrian Zubarev via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Okay now I feel like we’re merging everything we came up until now :D I’d
>>> love to see something like this happen to Swift, because `Any` seems to be
>>> a really powerful beast one day.
>>>
>>> One quick question: Do we really need this "This must be the first
>>> requirement, if present.“?
>>
>> I’m on the fence about this. The reason it would matter is for readability.
>> The counter argument to that is that you can’t rely on the first argument
>> being a class to determine whether a composed Any will have a class
>> constraint or not.
>>
>>>
>>> I’d say the compiler should reorder all types as it wants to. Current
>>> protocol<> already doing this today.
>>>
>>> e.g.
>>>
>>> protocol A {}
>>> protocol B {}
>>>
>>> typealias C = protocol<A, B>
>>> typealias D = protocol<B, A>
>>>
>>> print(C) // prints protocol<A, B>
>>> print(D) // prints protocol<A, B>
>>> print(C.self == D.self) // prints true
>>>
>>> Basically what I mean
>>>
>>> Any<SomeProtocol, class, AnotherProtocol>
>>>
>>> Any<Any<ProtocolA, ProtocolB>, UIView>
>>>
>>> should be valid.
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 18. Mai 2016 bei 18:30:02, Austin Zheng via swift-evolution
>>> ([email protected] <mailto:[email protected]>) schrieb:
>>>
>>>> I made heavy revisions to my proposal to reflect all the great feedback I
>>>> got from you and several other folks
>>>> (https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md
>>>>
>>>> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md>).
>>>>
>>>> Here are a couple of thoughts:
>>>>
>>>> - I used 'requirements' because that's how the grammar describes similar
>>>> constructs elsewhere in Swift. Open to change, though.
>>>>
>>>> - Having only one where clause makes complete sense. Protocol extensions
>>>> and generics all use one where clause, so should this construct.
>>>>
>>>> - The "P can be used in lieu of Any<P>" just means you can declare e.g. "x
>>>> : Equatable" if you want, instead of "x : Any<Equatable>", just like you
>>>> can with protocols without associated types or self requirements today.
>>>>
>>>> - I've come to the conclusion that it's probably best to propose the
>>>> proposal in the most general form, and allow any reviewers on the core
>>>> team to excise parts they don't think are useful enough or are too
>>>> difficult to implement. In that spirit, the 'simple Any<...>' construct is
>>>> gone and Any usage is fully general.
>>>>
>>>> - I moved discussion of typealiases back into the main protocol, like you
>>>> said, because typealiases using existentials are *not* actually generic
>>>> and can be done today.
>>>>
>>>> - I added some stuff about 'narrowing' existentials at point of use using
>>>> as?. This isn't part of 'opening existentials' and should fit in this
>>>> proposal nicely.
>>>>
>>>> - I want a type expert to look at the 'usage' section, but I'm reasonably
>>>> sure there's not much more flexibility we can give the user. Parameter
>>>> associated types can't be treated as covariant (they are almost always
>>>> invariant or contravariant IIRC) and therefore they should only be
>>>> accessible if fully bound. Return types can be treated as covariant; some
>>>> languages do and some don't. (Swift falls into the second bucket.) I would
>>>> love to be wrong, though.
>>>>
>>>> Austin
>>>>
>>>>> On May 18, 2016, at 8:45 AM, Matthew Johnson <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On May 18, 2016, at 2:35 AM, Austin Zheng <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>> I've put together a considerably more detailed draft proposal, taking
>>>>>> into account as much of Matthew's feedback as I could. You can find it
>>>>>> below:
>>>>>>
>>>>>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md
>>>>>>
>>>>>> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md>
>>>>>>
>>>>>> Since there is no chance this will come up for review anytime soon, I
>>>>>> expect to make significant revisions to it over the next month or so.
>>>>>> Any feedback would be greatly appreciated.
>>>>>
>>>>> Thank you for working on this! Great progress.
>>>>>
>>>>> Minor nit, but I think the proper word is constraint rather than
>>>>> requirement here:
>>>>>
>>>>> "Within the angle brackets < and > are zero or more requirements.
>>>>> Requirements are separated by commas."
>>>>>
>>>>> Another tweak:
>>>>>
>>>>> "P can be used in lieu of Any<P>, where P is a protocol with or without
>>>>> associated type or self requirements."
>>>>>
>>>>> This proposal is introducing generalized existentials. P and Any<P>
>>>>> should be interchangeable for any protocol regardless of requirements of
>>>>> the protocol. Existentials of protocols with self or associated type
>>>>> requirements that do not include constraints will just expose limited
>>>>> direct functionality. It would still be possible to attempt cast them to
>>>>> concrete types to recover more functionality. In the future (after a
>>>>> follow on proposal) it will also be possible to open the existential.
>>>>>
>>>>> Thorsten pointed out that there should only be one where clause for the
>>>>> whole existential. This follows the structure of generic type and
>>>>> function constraints. It may also be worth removing the 'as' alias from
>>>>> this proposal. This could be introduced as a stand alone proposal where
>>>>> it would apply to any context with generic constraints.
>>>>>
>>>>> Another item:
>>>>> // NOT ALLOWED let a : Any<Any<ProtocolA, ProtocolB>>
>>>>>
>>>>> Why is this not allowed? It is pointless, but should be allowed and
>>>>> considered identical to the flattened syntax.
>>>>>
>>>>> On dynamic casting, I don't believe it should be restricted in the way
>>>>> you have defined here. Casting *to* an existential doesn't have anything
>>>>> to do with opening an existential. We should allow casting to any
>>>>> existential type.
>>>>>
>>>>> On a similar note, I completely disagree with the limitation you specify
>>>>> for use of Any in generic constraints precisely because of your
>>>>> counterargument. In the discussion about moving the where clause it has
>>>>> been noted that sometime it is necessary to apply a lot of constraints to
>>>>> get the necessary effect. A mechanism for factoring constraints is
>>>>> highly desirable and will greatly improve the readability of generic
>>>>> code. Typealiases bound to Any can provide such a mechanism. Let's not
>>>>> artificially restrict the use of it.
>>>>>
>>>>> The section regarding members of a partly constrained existential needs
>>>>> to be more fleshed out. We can't simply punt it to a future proposal.
>>>>> However, I do think it is a good idea to wait until the core team has
>>>>> time to participate in the discussion.
>>>>>
>>>>> The section about defining typealias also should not be left to the
>>>>> future. It is possible to define typealias with protocol<> today and to
>>>>> use that alias in a generic constraint. Removing that capability would
>>>>> be a regression. In fact, it's utility will increase significantly with
>>>>> this proposal.
>>>>>
>>>>> In general, I don't think we need the distinction between simple and full
>>>>> Any. The whole idea of this proposal IMO should be fully generalizing
>>>>> existentials. If restrictions are necessary they should be due to
>>>>> (hopefully temporary) implementation considerations.
>>>>>
>>>>>>
>>>>>> Austin
>>>>>>
>>>>>> On Tue, May 17, 2016 at 9:52 PM, Austin Zheng <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, May 17, 2016 at 1:25 PM, Matthew Johnson <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Within the angle brackets are zero or more 'clauses'. Clauses are
>>>>>>>> separated by semicolons. (This is so commas can be used in where
>>>>>>>> constraints, below. Better ideas are welcome. Maybe it's not
>>>>>>>> necessary; we can use commas exclusively.)
>>>>>>>
>>>>>>> I’m not a fan of the semicolon idea. I don’t see any reason for this.
>>>>>>> The `where` keyword separates the protocol list from the constraints
>>>>>>> just fine. The list on either side should be able to use commas with
>>>>>>> no problem (or line breaks if that proposal goes through).
>>>>>>>
>>>>>>>
>>>>>>> I'm leaning towards getting rid of the commas, but would like to write
>>>>>>> out a few 'dummy' examples to see if there are any readability issues
>>>>>>> that arise.
>>>>>>
>>>>>> Replaced with what? Whitespace separation? I suppose that might work
>>>>>> for the protocol list but it feels inconsistent with the rest of Swift.
>>>>>> Commas plus (hopefully) the alternative of newline seem like the right
>>>>>> direction to me.
>>>>>>
>>>>>> Sorry, I completely misspoke (mistyped?). I meant I want to get rid of
>>>>>> the semicolons and use commas. I've come to the conclusion that there
>>>>>> are no readability issues, protocol<> already uses commas, and
>>>>>> semicolons used in this manner don't have a precedent anywhere else in
>>>>>> the language.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> There are five different possible clauses:
>>>>>>>>
>>>>>>>> 'class'. Must be the first clause, if present. Places a constraint on
>>>>>>>> the existential to be any class type. (Implies: Only one can exist.
>>>>>>>> Mutually exclusive with class name clause.)
>>>>>>>>
>>>>>>>> (In the future a follow-up proposal should add in 'struct' or 'value'
>>>>>>>> as a counterpart.)
>>>>>>>
>>>>>>> If we’re going to allow `struct` we should also allow `enum`. `value`
>>>>>>> would allow either of those.
>>>>>>>
>>>>>>>
>>>>>>> Of course. A future proposal can allow list members to discuss the
>>>>>>> exact details as to how struct, value, or enum specifiers should work.
>>>>>>
>>>>>> Yep, agree. Just mentioning that if we’re going to reference it we
>>>>>> should not leave obvious holes in what would be considered. :)
>>>>>>
>>>>>> Absolutely.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Class name. Must be the first clause, if present. (Implies: Only one
>>>>>>>> can exist. Mutually exclusive with 'class'.) Places a constraint on
>>>>>>>> the existential (not really an existential anymore) to be an instance
>>>>>>>> of the class, or one of its subclasses.
>>>>>>> It is still be an existential if it includes protocol requirements that
>>>>>>> the class does not fulfill. For example, you might have Any<UIView,
>>>>>>> SomeProtocol> where UIView does not conform to SomeProtocol, but
>>>>>>> various subclasses do.
>>>>>>>
>>>>>>>
>>>>>>> Fair enough. (I don't think the way things work would be affected.)
>>>>>>>
>>>>>>> Your proposal doesn’t discuss composing Any in the way that Adrian’s
>>>>>>> did like this:
>>>>>>>
>>>>>>> typealias Foo = Any<SomeClass, SomeProtocol, OtherProtocol>
>>>>>>> Any<AnotherProtocol, Foo>
>>>>>>>
>>>>>>> I didn't think it needed to be discussed. An Any<...> existential type
>>>>>>> is a type 'expression' just like any other, and should be allowed to
>>>>>>> participate in other Any<...>s.
>>>>>>>
>>>>>>>
>>>>>>> I like the idea of composition as it allows us to factor out
>>>>>>> constraints. If we are going to do that we should allow a class to be
>>>>>>> specified in the composition as long is it is a subclass of all class
>>>>>>> requirements of Any types it composes. For example, this should be
>>>>>>> allowed:
>>>>>>>
>>>>>>> typealias Bar = Any<SubclassOfSomeClass, Foo, AnotherProtocol>
>>>>>>>
>>>>>>> This is still one class requirement for Bar, it just refines the class
>>>>>>> requirement of Foo to be SubclassOfSomeClass rather than just SomeClass.
>>>>>>>
>>>>>>> This is a good point. There should be clarification as to how special
>>>>>>> cases of Any<...> used in another Any<...> behave. For example, like
>>>>>>> you said Any<MyClass, Any<SomeSubclassOfMyClass, Protocol>> should be
>>>>>>> valid. This will go into any proposal that emerges from the discussion.
>>>>>>
>>>>>> Yes, this is why we need to discuss Any composition. There are also
>>>>>> cases of incompatible associated type constraints which need to be
>>>>>> rejected (such as composing two Any’s where one has Element == String
>>>>>> and another has Element == Int).
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Example: Any<UIViewController; UITableViewDataSource;
>>>>>>>> UITableViewDelegate>
>>>>>>>> "Any UIViewController or subclass which also satisfies the table view
>>>>>>>> data source and delegate protocols"
>>>>>>>> Dynamic protocol. This is entirely composed of the name of a protocol
>>>>>>>> which has no associated types or Self requirement.
>>>>>>>> Example: Any<CustomStringConvertible; BooleanType>
>>>>>>>> "Any type which conforms to both the CustomStringConvertible and
>>>>>>>> BooleanType protocols"
>>>>>>>>
>>>>>>>> I'm going to use 'static protocol' to refer to a protocol with
>>>>>>>> associated types or self requirements. Feel free to propose a more
>>>>>>>> sound name.
>>>>>>>>
>>>>>>>> Self-contained static protocol, simple. This is composed of the name
>>>>>>>> of a static protocol, optionally followed by a 'where' clause in which
>>>>>>>> the associated types can be constrained (with any of the three basic
>>>>>>>> conformance types: subclassing, protocol conformance, or type
>>>>>>>> equality). Associated types are referred to with a leading dot.
>>>>>>> Please do not introduce terms “dynamic protocol” and “static protocol”.
>>>>>>> We want to support existentials of protocols that have self or
>>>>>>> associated type requirements. The dynamic vs static distinction is a
>>>>>>> limitation of the current implementation of Swift and doesn’t make
>>>>>>> sense for the long term vision.
>>>>>>>
>>>>>>> I'm not trying to introduce new terms, these are just placeholders. At
>>>>>>> the same time "protocols with self or associated type requirements" is
>>>>>>> cumbersome to work with and it would be nice for someone to come up
>>>>>>> with a descriptive term of art for referring to them.
>>>>>>
>>>>>> I agree that a better term would be useful. In the meantime, I would
>>>>>> prefer something like “trivial” and “nontrivial” protocols.
>>>>>>
>>>>>> I've decided to just use the full name until the community comes up with
>>>>>> better names. Clarity is preferable to brevity in this case.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Example: Any<Collection where .Generator.Element : NSObject,
>>>>>>>> .Generator.Element : SomeProtocol>
>>>>>>>> "Any type that is a Collection, whose elements are NSObjects or their
>>>>>>>> subclasses conforming to SomeProtocol.”
>>>>>>>
>>>>>>> Swift does not allow disjunction of requirements. Only conjunctions
>>>>>>> are supported. That means the correct reading is:
>>>>>>>
>>>>>>> "Any type that is a Collection, whose elements are NSObjects and their
>>>>>>> subclasses conforming to SomeProtocol.”
>>>>>>>
>>>>>>>
>>>>>>> Yes, that is what I meant. "whose elements are (NSObjects or their
>>>>>>> subclasses) conforming to SomeProtocol”.
>>>>>>
>>>>>> Ok, good. Wasn’t quite clear to me.
>>>>>>
>>>>>> Yes, the verbiage will need to be clearer in the future. That sentence
>>>>>> could be ambiguously parsed.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Bound static protocol. This is the same as a self-contained static
>>>>>>>> protocol, but with a leading "<name> as " which binds the protocol to
>>>>>>>> a generic typealias. The name can be then be used in subsequent
>>>>>>>> clauses to build constraints.
>>>>>>>>
>>>>>>>> Example: Any<T as Collection; IntegerLiteralConvertible where
>>>>>>>> .IntegerLiteralType == T.Element>.
>>>>>>>> "Any type that is a Collection, and also can be built from an integer
>>>>>>>> literal, in which the collection elements are the same type as the
>>>>>>>> type of the integer used for the integer literal conformance.”
>>>>>>>
>>>>>>> I’m not sure about this, but if we’re going to do it it should be the
>>>>>>> other way around: `Collection as T` with the alias after the name of
>>>>>>> the protocol.
>>>>>>>
>>>>>>>
>>>>>>> I like this, it flows better. "Protocol as T where Protocol.Foo == Int,
>>>>>>> Protocol.Bar : Baz”.
>>>>>>
>>>>>> Why did you introduce an alias here and then not use it? Did you mean
>>>>>> "Protocol as T where T.Foo == Int, T.Bar : Baz"
>>>>>>
>>>>>> Another result of rushing to compose an email. Sorry!
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> You are also using “dot shorthand” here to refer to an associated type
>>>>>>> of IntegerLiteralConvertible. I think “dot shorthand” should be
>>>>>>> limited to cases where there is only one protocol that is getting
>>>>>>> constrained. In other cases, we need to be clear about which protocol
>>>>>>> we are referring to.
>>>>>>>
>>>>>>> I borrowed dot shorthand from the generics manifesto. But you are
>>>>>>> right, it should only be allowed if there is one protocol with
>>>>>>> associated types or self requirements clause in the Any<...>
>>>>>>> construction.
>>>>>>
>>>>>> I would actually go further and limit it to one protocol period, and
>>>>>> possibly even to one protocol and no type names (as types can have
>>>>>> nested types and typealiases). When we allow shorthand it should be
>>>>>> immediately unambiguous what the shorthand references with no need to
>>>>>> look at type or protocol declarations.
>>>>>>
>>>>>> It might be desirable to propose the proposal with no allowance for
>>>>>> shorthand, and have the dot shorthand be a smaller follow-up proposal.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> There will be rules to prevent recursive nesting. For example, if
>>>>>>>> generic typealiases are allowed, they cannot refer to each other in a
>>>>>>>> circular manner (like how structs can't contain themeselves, and you
>>>>>>>> can't create a cyclic graph of enums containing themselves).
>>>>>>>>
>>>>>>>> How an existential can be used depends on what guarantees are provided
>>>>>>>> by the clauses. For example, 'Any<Equatable>' can't be used for much;
>>>>>>>> if there were any methods on Equatable that did not use the associated
>>>>>>>> types at all you'd be able to call them, but that's about it. However,
>>>>>>>> 'Any<Equatable where .Self == String>' would allow for == to be called
>>>>>>>> on instances. (This is a stupid example, since Any<Equatable where
>>>>>>>> .Self == String> is equivalent to 'String', but there are almost
>>>>>>>> certainly useful examples one could come up with.)
>>>>>>>>
>>>>>>>> In order of increasing 'power':
>>>>>>>> Don't constrain any associated types. You can pass around
>>>>>>>> Any<Equatable>s, but that's about it.
>>>>>>>> Constrain associated types to conform to protocols.
>>>>>>>> Fully constrain associated types.
>>>>>>>
>>>>>>> I think we need to spell out pretty clearly what members we expect to
>>>>>>> be available or not available. This section probably needs the most
>>>>>>> design and elaboration.
>>>>>>>
>>>>>>> For example, we probably can’t access a member who uses an associated
>>>>>>> type as an input unless it is constrained to a specific type. On the
>>>>>>> other hand output types probably don’t need to limit access to a
>>>>>>> member. However, if the output type is Self or an associated type the
>>>>>>> visible signature would have an output type which has the relevant
>>>>>>> constraints of the existential applied, but no more. In some cases
>>>>>>> this means the output type would simply be Any.
>>>>>>>
>>>>>>> Absolutely. This is vaguely what I had in mind but I wanted to get
>>>>>>> something down first. Thanks for thinking through some of the
>>>>>>> implications :).
>>>>>>
>>>>>> That’s what I thought. Just wanted to start the process of elaborating
>>>>>> expectations.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Where this really gets tricky is for compound types like functions,
>>>>>>> generic types, etc. Working out the details in these cases is pretty
>>>>>>> complex. I will defer to Doug on whether it is best to just defer
>>>>>>> those cases to the future, leave them up to the implementer, or try to
>>>>>>> work out all of the relevant details in the proposal (in which case we
>>>>>>> probably need a type system expert to help!).
>>>>>>>
>>>>>>> Yes, exactly! For example, can Any<...> existentials involving
>>>>>>> protocols with associated types or self requirements be used within
>>>>>>> generic function or type definitions? Maybe there's an argument that
>>>>>>> existential types of this nature are redundant if you have access to
>>>>>>> generics (e.g. defining a property on a generic type that is a
>>>>>>> Collection containing Ints; you should be able to do that today). On
>>>>>>> the other hand, maybe there are use cases I haven't thought of…
>>>>>>
>>>>>> I see no reason they shouldn’t be. They are not redundant at all. For
>>>>>> example, you may want to store instances in a heterogeneous collection.
>>>>>> You need existentials to do that.
>>>>>>
>>>>>> A simple example of what I was referring to there is something like this:
>>>>>>
>>>>>> protocol P {
>>>>>> associatedtype Foo
>>>>>>
>>>>>> func bar(callback: (Foo) -> ())
>>>>>> }
>>>>>>
>>>>>> In other words, types in the signature of a protocol member are complex
>>>>>> types that reference Self or associated types. I think you really need
>>>>>> a formal understanding of the type system to understand how to expose
>>>>>> these members through a constrained existential. We can probably
>>>>>> understand the expected behavior in some of the simpler cases on a case
>>>>>> by case basis, but that approach doesn’t scale at all and is arbitrary.
>>>>>> If they’re going to be supported an expert is going to need to be
>>>>>> involved in the design.
>>>>>>
>>>>>> Yes. I have some ideas regarding this topic.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> One area you didn’t touch on is “opening” the existential? Is that out
>>>>>>> of scope for this proposal? That would be fine with me as this
>>>>>>> proposal is already taking on a lot. But if so, you should mention
>>>>>>> something about future directions as it is pretty closely related to
>>>>>>> this proposal.
>>>>>>>
>>>>>>> Yes, existential opening is explicitly separate from this (although I
>>>>>>> wanted to mention it in the section where I talk about how
>>>>>>> Any<Equatable> is not very useful). But you are absolutely right, this
>>>>>>> proposal should discuss how it wants to interact with possible future
>>>>>>> directions.
>>>>>>>
>>>>>>>
>>>>>>> Another area you didn’t touch on is whether Any constructs (and
>>>>>>> typealiases referring to them) should be usable as generic constraints.
>>>>>>> I would expect this to be possible but I think we need to spell it out.
>>>>>>>
>>>>>>> I'm hoping for community input. This is a tricky subject, and at some
>>>>>>> point we'll bump into implementation limitations.
>>>>>>
>>>>>> I don’t think it’s too tricky. You can just unpack the constraints of
>>>>>> the Any into the list of generic constraints. Maybe I’m missing
>>>>>> something, but I don’t think so.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Matthew
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
