Good point. :)
I’ve been thinking if there is a way to still have a shiny and swifty looking
syntax which would solve this problem:
typealias SomeExistential<T> = existential<T> {
constraint UIView
constraint ProtocolA
constraint ProtocolB.AssociatedType == T
var someVar: Int { get set }
}
This mimics typealias Name = protocol<…> where the protocol<…> does not have an
explicit name.
One downside of this approach:
To use such an existential you would need give it a name trough typealias.
typealias AnyCollection<T> = existential<T> {
constraint Collection
constraint Collection.Element == T
}
--
Adrian Zubarev
Sent with Airmail
Am 26. Mai 2016 bei 22:56:10, Matthew Johnson ([email protected]) schrieb:
On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution
<[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.
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]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
