Types from Swift Standard Library as a generic type

Evolution Discussion
6

I personally consider shadowing a bad practice, at least if there is no obvious reasoning for it like readability of an API. Since I'm no compiler developer I can only guess that not every shadowing scenario can be captured/handled by the compiler or even should. There are likely to be some examples out there where you want to shadow the generic type of the enclosing generic context but also at the same time want to be able to reference it.

Here is one non-valid example where shadowing is a consequence of nesting:

struct FirstDimension<Element> {
	struct SecondDimension<Element> where Element == FirstDimension.Element {
		...
	}
}

However that requires a feature that we still don't have in Swift, qualified lookup for generic type parameters. I discussed this topic in more detail in this thread.

Long story short, I personally wouldn't support the proposed restrictions as they already would prevent code to compile in some of my codebases (e.g. Result as a generic type parameter name). Even though I don't care much about breaking changes, the benefit of this special case does not outweigh the consequences from my perspective.

If someone can present some strong arguments why we really should apply that special case, I'd be happy to re-consider my view point. :+1:

1 Like