Consider using "and" in type constraints instead of "&"

[nadiasvertex]

I note that the operator for combining boolean expressions is "and", not "&&". The bitwise "and" operator remains "&". Therefore, it is surprising that combining constraints is done with "&" instead of "and". I understand that one can make arguments that the two things are different. However, in an issue for leads one justification for using "&" is:

• Reads naturally as "and"

Why not just be consistent and use "and" in both places?

[chandlerc]

We adopted and (as a keyword) in expressions specifically because it has control flow behavior -- it short circuits and doesn't keep evaluating.

For constraints, the semantics don't match that -- there isn't a short-circuit step, and so I think it would be confusing to use and there personally.

Marking this as a fresh question for leads just to confirm.

[nadiasvertex]

Are you sure that the behavior is not effectively the same as short-circuit? If I want "constraint1 and constraint2 and constraint3", but constraint2 fails are you really going to keep matching? And frankly, what if you did? From the user's standpoint it means the same thing. You aren't going to go ahead and say that the constraint expression matches even if one component fails. Otherwise, what would be the purpose of the constraint at all? :-)

[borisalmonacid]

#andteam here :)

[jonmeow]

An alternative to consider here might be union and intersect keywords, if the goals to use a textual keyword. This would mirror union and intersection type naming.

[nadiasvertex]

I think that is the real point. I don't have a strong opinion either way, but you should be consistent.

[OlaFosheimGrostad]

Are you sure that the behavior is not effectively the same as short-circuit? If I want "constraint1 and constraint2 and constraint3", but constraint2 fails are you really going to keep matching?

So, this makes sense if you think of it as a requirement tied to the presence of methods, then A&B can shortcut if the type is missing one method in A. But if you think of A&B as a new type that can take instances that can both be used as an A and also a B, then there would no shortcut.

E.g. if you extend this to values, then A&B should be the set of values that is in the set of both A and B. So i32&i16 :=: i16. It is still not a big problem to use 'and' instead of '&', though, although you would intuitively expect the wording 'i32 and i16' to be i32 and not i16, so it becomes counter-intuitive?

Where using 'and' instead of '&' gets really messy is when you allow more complex type expressions with booleans in the future, then 'and' would take on two different meanings in the same expression and that would be hard to read.

[nadiasvertex]

Where using 'and' instead of '&' gets really messy is when you allow more complex type expressions with booleans in the future, then 'and' would take on two different meanings in the same expression and that would be hard to read.

That is interesting. It creates new problems, though. If "&" means intersection, then I still need a way to say "all from A and all from B" not just "all the things A and B have in common". @jonmeow mentioned "union" and "intersection" earlier, and I think it would be clearer to use those words than try to explain two operators and the difference between them.

[OlaFosheimGrostad]

That is interesting. It creates new problems, though. If "&" means intersection, then I still need a way to say "all from A and all from B" not just "all the things A and B have in common". @jonmeow mentioned "union" and "intersection" earlier, and I think it would be clearer to use those words than try to explain two operators and the difference between them.

Yes, probably, but 'intersection' will make the function signatures rather verbose. But '&'/'&&' are overutilized in C++: and, bitand, address-of, reference-type, move-type…

I think Carbon currently has made it difficult by requiring that all sigils/characters must be easily accessible by keyboard. And what does that mean in an international context? I have to press 3 keys on my norwegian keyboard to get '{' for instance!! :-D

[chandlerc]

Based on discussion with the leads, I think we're not going to go with this specific issue: using and instead of &.

I do want to call out that we're actively interested in well motivated other syntaxes here, especially ones that avoid re-using an operator that is used at the value level. But it seems like those would be best in their own issue or proposal with clear motivation for which option and making sure the result reads well and isn't too verbose, etc.