Semantically, a conditional extension and a direct where clause are equivalent. When the compiler is capable of knowing whether the constraints are satisfied beforehand, foo must only be visible when the receiver satisfies those constraints. As you demonstrate with foo<T>() where Wrapped == T?, sometimes this isn't possible, so you are allowed to access the member and specialize any generic parameters before the compiler can jump to any conclusions on whether you can actually use it.
The key difference in placing constraints on a requirement is that we can dynamically dispatch to a constrained declaration. Answering your first question, it is also a limitation we can pass through Evolution and implement in the future.
It would be possible but I don't think we want to do that. Mangling for nested entities intentionally reflects the lexical structure, so that, for example, Demangle::getTypeForMangling() can easily find the declaration. If you mangle declarations with a where clause as if they were part of a fake constrained extension it would complicate code like that.
Also, we already mangle generic declarations with where clauses that reference outer parameters differently from constrained extension members, so introducing a special case here is even more error prone.
@core-team Would anyone like to step up to manage the review of this proposal? There doesn't seem to be too much going on in the Proposal Reviews category right now.
@anthonylatsis, @Slava_Pestov, @Joe_Groff
Would it be more convenient to rather introduce an Adopter keyword to specify type constraints on concrete type, instead of ambiguous Self, since protocol can only be conforming by concrete types?
struct Foo<T>: Sequence
extension Sequence where Adopter == Foo {
func regular() where Adopter.T: HomogeneousCollection
func specialCase() where Adopter.T == Character
func optimized() where Adopter.T: MutableCollection,
Adopter.T.Element: Numeric
}
That has nothing to do with ambiguity. It makes a protocol requirement conditional. What would it even mean to have a conditional requirement? This would be much more cleanly modeled with a refining protocol:
protocol Q: P, Equatable {
func foo()
}
With this approach, the constraint and requirements that depend on it are moved to the refining protocol Q and there is no need to have a notion of “conditional protocol requirement” in the language.
Yeah, Self constraints on protocol requirements is a feature we haven't modelled or implemented yet, so they do not work with or without this proposal. To clarify this is the purpose of the introduction note demonstrating the error.
I’m sorry if this question has been asked before or if it’s off-topic here, but I was wondering if “where” clauses on contextually generic declaration includes protocol typealiases. Countless times I find myself yearning for the ability to do this:
I know that it's just a throwaway example, and sorry for being offtopic, but I would be wary of that typealias - Having integer indices isn't sufficient to be arraylike. For example ArraySlice doesn't have to start with zero, and LazyFilterSequence can have gaps between indices
This is more about generalized existentials. In this case the real issue is that no one has taught the compiler how to look up Index. So the where clause cannot be attached is currently just masking the real issue. This is what happens if you declare such a type alias inside a generic context with this proposal implemented:
struct Wrapper<T> {
// error: use of undeclared type 'Index'
typealias ArrayLike = RandomAccessCollection where Index: BinaryInteger
}
I’ve actually resorted to doing this in cases, where the number of implementors of the protocol are limited and I can just conditionally conform all the implementors to this stub protocol. However, this approach won’t work if the original protocol isn’t supposed to be “sealed”, because then the implementor will have to remember to explicitly conform to the stub protocol.
I’m not familiar with compiler internals, so I can‘t tell if this is a purely syntactic issue, or there is some crucial shortcoming in the compiler’s internal representation of the code being compiled that prevents this feature from happening. Syntactically, it looks like, a protocol type alias doesn’t “spill” its associated types into the current syntactic context (which ends with the end of the type alias declaration), as opposed to a generic type alias, which does so with its generic parameters. It seems to me like opaque result types suffer from the same problem, where the opaque result type doesn’t “spill” its associated types into the syntactic context of the function declaration, making it impossible to declare a function that returns an opaque collection of non-opaque elements.
By the way, is this the same reason why we still have to manually implement type-erasing wrappers like AnyIterator?
It is by far not just a syntactic issue. As you noted, opaque types do not support any direct constraints yet. This is something that would require a lot of effort to implement altogether.
Thanks a lot for your detailed explanation! I just have two more questions left: how important is the implementation generalized existentials to the currebt Swift roadmap and is there any documentation of the swift compiler internals for me to study in order to contribute.
This sounds like the holy grail of swift evolution and I’d really like to live long enough to see it happen!
Not sure about the holy grail, but certainly an important step. The several *Manifesto documents in the docs folder will give you a general overview on the roadmap. I am just a contributor myself, so there's hardly anything more exhaustive I can offer.
Regarding the compiler, you may want to search for relevant topics in the compiler category. Here's one.
I just have two more questions left: how important is the implementation generalized existentials to the currebt Swift roadmap and is there any documentation of the swift compiler internals for me to study in order to contribute.