The ambiguity of `where` clause to the reader

Evolution Discussion
1

I was browsing some APIs and one thing got my attention very quickly. I was looking at the following definition while my mind immediately thought of conditional conformances, until I realized that the context was not an extension.

// (original) not conditional conformance
struct KeyedEncodingContainer<K> : KeyedEncodingContainerProtocol where K : CodingKey { ... }

// (non-existing API) conditional conformance
extension KeyedEncodingContainer : KeyedEncodingContainerProtocol where K : CodingKey { ... }

Maybe we should consider to rename the where keyword in some contexts to allow new features like conditional conformances directly from type declarations (here the first where clause would become ambiguous)?

What do you think?

2

I don’t see the point. We already have keywords/operators that serve multiple purposes now. For example the “as” operator has multiple meanings depending on if you’re doing casting vs a pattern match in a switch.

Plus in English (and most natural languages) words are allowed to have multiple meanings. And I can’t think of a good alternative for these contexts.

3

Well as it's right now there is no way to allow conditional conformances directly from the type declaration, and I'm not trying to say that we ever should, but just noting this fact. If we ever would want that feature then the reused where clause for constraints would become ambiguous.

Here is some bikeshedding code:

struct Generic<T> : Codable where T : Codable constraints T : Hashable { ... }

The only requirement for T is to conform to Hashable while there is also a included conditional conformance.

Again that's just a few thoughts I had, not a pitch, just wanted to ask what others might think of it. ;)

4

There’s also the “where” guard in for loops. So I agree “where” does have a lot of contextual meanings. But I think they all hold their weight.

5

I see the use case. I’ve just never reached for that functionality, unlike conditional conformance in extensions, so I don’t see the value

2 Likes
6

I'm not sure I understand what this would mean. I guess in the body of the struct definition, Generic wouldn't be considered Codable, so you couldn't use Codable functionality. It's hard for me to imagine this being implemented, since it's confusing and seemingly of little use.

7

-1

It is expressing a constraint in both situations, in my reading. We constrain K completely while declaring the type. We constrain the extension by constraining K conditionally in the extension.

8

-1

I can't see why we would like to have conditional conformance in type declaration. That would be far more confusing than have where used for 2 purposes.

9

Again, I'm not pitching anything here. Just asking if somebody ever thought that the where clause reads ambiguous in some cases compared to others, not more not less. ;) So there is no need for "-1" round here.

10

Maybe we should consider to rename the where keyword in some contexts to allow new features like conditional conformances directly from type declarations

You are proposing to rename it to allow new features. If such features does not exists, why would you break existing sources. There is no ambiguity about what where means. In both cases, it express a restriction about the type.

11

I was not proposing anything, I was asking what other people think. This is a discussion thread not a pitch thread.

12

I don't think that we should rename the where keyword in any of the presented cases. I think that allowing conditional conformances directly on type declarations would be ambiguous. Forcing conditional conformance to be declared on an extension seems like a clarifying action.

4 Likes