> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution
> <swift-evolution@swift.org> 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.
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
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
