Implicit/inferred generic type constraints

[josh11b]

Question: Should the following compile, or should the compiler require that the user explicitly list all of HashSet's requirements for KeyType?

class HashSet(KeyType:! Hashable & HasEquals & Movable);
fn Contains[KeyType:! Type](needle: KeyType, haystack: HashSet(KeyType)) -> Bool;
fn Print[KeyType:! Printable](set_to_print: HashSet(KeyType));

• Swift supports this: 1, 2
• Inside Contains, KeyType would satisfy those interfaces but it would be like the interfaces were implemented externally, without including the names from those interfaces as unqualified members of KeyType
• This would only be for function signatures, not interfaces where there are additional considerations.

Implicit constraint option

Advantages:

• More concise, benefiting readers and writers of the code.
• Doesn't included redundant information, following the "don't repeat yourself" principle.
• Callers providing a haystack value of type HashSet(KeyType) already establishes that they have satisfied the constraints.
• Allows HashSet to evolve its requirements with fewer changes to the code.

Disadvantages:

• This may introduce additional complications once we allow specializations of HashSet, which might possibly allow HashSet(T) for some T that doesn't satisfy the general requirements.
• Less explicit.

Opt-in

Another choice would be to have an explicit mark indicating that the requirements should be determined automatically for an indicated generic type parameter.

fn Contains[KeyType:! implicit_requirements]
           (needle: KeyType, haystack: HashSet(KeyType)) -> Bool;
fn Print[KeyType:! Printable & implicit_requirements]
           (set_to_print: HashSet(KeyType));

We might use the keyword auto here, but I worry that is more closely associated with template semantics.

No implicit constraints

Users would be expected to list all requirements.

[chandlerc]

Just a clarifying question from my end:

Question: Should the following compile, or should the compiler require that the user explicitly list all of HashSet's requirements for KeyType?

class HashSet(KeyType:! Hashable & HasEquals & Movable);
fn Contains[KeyType:! Type](needle: KeyType, haystack: HashSet(KeyType)) -> Bool;
fn Print[KeyType:! Printable](set_to_print: HashSet(KeyType));

• Swift supports this: 1, 2
• Inside Contains, KeyType would satisfy those interfaces but it would be like the interfaces were implemented externally, without including the names from those interfaces as unqualified members of KeyType

Would this implicitly be equivalent to the type-expression constraint syntax from #780 of:

fn Contains[KeyType:! Type](needle: KeyType, haystack: HashSet(KeyType) where KeyType is (Hashable & HasEquals & Movable)) -> Bool;

fn Print[KeyType:! Printable](set_to_print: HashSet(KeyType) where KeyType is (Hashable & HasEquals & Movable));

?

[josh11b]

Yes, they both would add those constraints as if they were external impls.

[chandlerc]

FWIW, thinking about this I'm pretty happy with the idea that constraints on an interface parameter are handled the same as constraints explicitly listed in a where type expression on that interface. It seems clear and easy to explain and provides a pretty significant ergonomic aid and even refactoring aid I suspect.

I'm of course worried by the additional complications if they come up, but I think I'd be willing to cross that bridge when we get there.

[josh11b]

Are we ready to resolve this question? If we are including this feature, what should I call it? Possibilities:

• implicit constraints
• implied constraints
• inferred constraints

[zygoloid]

For terminology, I think I prefer "implied constraints"; it's a bit easier to say than "implicit constraints", and it connects the implication to a specific context (for example, the constraints in the original example are implied by the use of HashSet). "inferred constraints" sounds a bit too much like a description of how rather than what.

But I'd also be happy with "implicit constraints".

[zygoloid]

Decision: Yes, examples such as the original one should compile without requiring the constraints to be duplicated in the function declaration. Our preferred terminology for this is "implied constraints".

[jonmeow]

I think this may not still need a proposal, looks like #818 was probably filling that need.

[chandlerc]

I think this may not still need a proposal, looks like #818 was probably filling that need.

@josh11b to confirm.

[josh11b]

I think this may not still need a proposal, looks like #818 was probably filling that need.

@josh11b to confirm.

Confirmed, #818 addressed this.