> On May 27, 2016, at 6:02 AM, L. Mihalkovic <[email protected]>
> wrote:
>
>
> On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>>> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>>> I alway enjoy hearing your ideas.
>>>>>
>>>>> This is quite interesting. It's basically a way to define an ad-hoc
>>>>> interface that a type doesn't need to explicitly declare it conforms to.
>>>>> I know Golang works similarly; if a Go type implements all the
>>>>> requirements of an interface it conforms automatically.
>>>>>
>>>>> There are positives and negatives to allowing this sort of ad-hoc
>>>>> interface.
>>>>
>>>> Agree. It would definitely make the language "feel" a bit more fluid.
>>>> But it doesn't add any expressive power and could have undesirable
>>>> consequences.
>>>>
>>>>> This would make for a good standalone proposal -- both because it's
>>>>> complex enough to deserve its own discussion, and because if the
>>>>> community is interested someone would have to work through all the
>>>>> implications in order to put together a proposal. It would be quite a big
>>>>> change.
>>>>
>>>> I don't see how this is different from a protocol other than the lack of
>>>> requirement to declare conformance explicitly. The need to explicitly
>>>> declare conformance is a design decision that I believe the core team
>>>> feels pretty strongly about.
>>>>
>>>> That said, it hasn't been debated by the community yet so if someone feels
>>>> strongly about dropping explicit conformance declarations it might be
>>>> worth pitching the idea, if for not other reason than to have a discussion
>>>> about it on the lost.
>>>
>>> I don’t see any desire to follow Go’s path here and drop explicit
>>> conformance in any way.
>>>
>>> Basically such `existential` mechanism could express more than `Any<…>`
>>> could. That said I do feel that this "could“ have some potential to exist
>>> alongside `Any<…>`.
>>>
>>>
>>
>> Anything “more” it could express would be specific member requirements,
>> which would make it in some sense ad-hoc protocol. I would rather see one
>> mechanism for defining member requirements. We already have that and it is
>> called a protocol.
>>
>> The reason types won’t need to declare explicit conformance to an `Any` is
>> that the requirements of the `Any` are composed of an optional supertype as
>> well zero or more protocol and associated type constraints. The
>> “conformance" of a type to the `Any` is defined by its conformance to the
>> protocols that the `Any` is composed of.
>>
>> If you want to introduce new requirements the right way to do it is to
>> declare an additional protocol and add it to the list of protocol
>> constraints in the `Any`.
>>> From my understanding of this whole existential type thing is that it can
>>> be used both ways, explicitly and implicitly. As said before we only
>>> discussed the explicit existential types.
>>>
>>>
>>>
>>> Just another pseudo example:
>>>
>>> ```swift
>>>
>>> // this could also replace typealiases for (generic) existentials
>>>
>>>
>>
>> I gave some consideration to scoped syntax like this a few days ago. The
>> problem with it is that `Any` is a structural type defined by the
>> constraints and this makes it look like a nominal type.
>
> I am not sure I follow you.. If Any is a structural type, then case closed,
> it is instantiate-able and carry all the normal behavior of all other
> structural types. Or is it a wolf in sheep's clothing that is actually
> neither a wolf, nor a sheep?
It is defined by the structure of the constraints, not the structure of the
data.
>
> This is ultimately coming back to my earlier question of how does one
> differentiate between X<...> and Y<...>?
>
> Should we read the angle brackets first and reach the logical (but wrong)
> conclusion that X and Y will essentially behave in a similar fashion, or
> should we read the names first and remember that we have to go to two
> different pages of the swift programmer's guide to make sense of what follows?
>
> As was previously said with great eloquence (i believe by Joe Groff), Any<>
> is something only a compiler loves... I would like it if we found something
> both the swift compiler and the swift programmer could love.
It isn’t entirely clear to me what you’re arguing for here. It *seems* like
maybe your advocating for the `&` syntax (or similar) to make a stronger
differentiation from generic types. That makes sense.
The point I was making is that any names we give to an existential type are
*aliases* for it. The name doesn’t matter as far as the type system is
concerned. The syntax Adrian posted makes it *look* like the name actually
matters to the type system IMO and introduces potential for confusion because
of that.
>
>
>>
>> If you define two “existential” types with the exact same constraints under
>> different names, what happens? They should be identical to other any
>> equivalent formulation and that is clear under Austin’s proposal, but
>> because this alternative looks like a nominal type you might have the
>> expectation that the types are independent of each other. That is why
>> typealias is the correct solution here IMO. It is clear that the name is
>> just an alias for a structural type.
>>> existential CrazyView {
>>>
>>> // we could introduce a way for constraints which could have a nice
>>> looking syntax
>>>
>>> // break `Any<…>` nesting and long very long composition lines of
>>> `Any<…>`
>>>
>>> constraint Any<UIScrollView, Any<UITableView, Any<UIView, ProtocolA>>>
>>>
>>> constraint ProtocolA.AssociatedType == Int
>>>
>>> func crazyFunction()
>>>
>>> }
>>>
>>>
>>>
>>> existential AnyCollection<T> {
>>>
>>> constraint Collection
>>>
>>> constraint Collection.Element == T
>>>
>>> }
>>>
>>> ```
>>>
>>> But I don’t want to go any further if there is no need (yet).
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> _______________________________________________
>>> 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
