I don't think it's possible, or even desirable, to define a single syntax that could work both in a context where the where
clause clearly refers to, and only to, a specific parameter, and in a context where where
introduces a list of constraints that refer to several parameters at once.
Your examples 5
and 6
show a case where the where
clause unambiguously refers to a specific parameter, so there's no real need to name it:
struct AltExample5 {
var x: any Strawman where Input == Int
}
struct AltExample6 {
var x: some Strawman where Input == Int
}
this breaks if we add structure, for example in case of tuples or some other type with generic parameters:
struct AltAltExample5 {
var x: (any Strawman, any Foo) where Input == Int // ambiguous
}
struct AltAltExample6 {
var x: Result<some Strawman, some Foo> where Input == Int // ambiguous
}
which means, to me, that we could introduce named parameters only if needed, that is, to remove ambiguity when it presents itself. The compiler could help here, with an error that clearly suggests to introduce named parameters when needed.
In case of functions, the situation seems very similar, with the only difference that having more parameters, thus potential ambiguity, is simply more likely to happen. In theory, your first 2 examples could work without named parameters:
func example1(_ x: some Strawman)
where Input == Int
func example2(_ x: any Strawman)
where Input == Int
but once we add more parameters or return types, either because with both have input and output generics, or due to "structural" opaque return types, the only way to resolve ambiguity would be to name them, unless we attach a where
clause to every single parameter for which additional constraints are declared.
But naming parameters is really only needed if we want to:
- put together constraints for multiple type parameters in a single place;
- cross-reference type parameters when declaring constraints;
If we decide for a smaller, simpler goal, and leave "total generality" to explicit declaration of type parameters in angle brackets, we can think about ways to attach additional constraints to some
and any
type parameters directly, without a detached where
clause.
For example, some Strawman<.Input == Int>
has beed proposed several times, but I'm not a fan of it for reasons I laid out above. some Strawman(.Input == Int)
could be interesting, also:
-
some Strawman(Input == Int)
; -
some Strawman(where Input == Int)
; -
(some Strawman where Input == Int)
.