The Scala book page currently at Intersection Types | Scala 3 — Book | Scala Documentation says:
The members of an intersection type
A & Bare all the members ofAand all the members ofB.
The members of an intersection type A & B is only those members of type A that are also members of type B, right?
(The phrase “all the members of A and all the members of B” describes the members of a union type A | B, doesn’t it? Or am I missing something I’m not seeing yet?)
Union type will only have members common to both - because they come from the common super type. So for Int | String thats basic methods on Any such as .toString only
Intersection type creates a new subtype that does indeed have all aspects of both sides - sometimes this is impossible such as Int & String but you will not be able to reach code that tries to call a method on such a type
Ah, I see the problem: The book’s text uses “member” ambiguously.
An intersection type A & B is called an intersection type because the set of values in that intersection type is the intersection of the set of values of type A and the set of values of type B. That is, the members of the intersection type are the values each of which is both a member of set A and a member of set B.
So the name “intersection type” certainly sets the stage for interpreting “member” in that sense (of a value being member of a set).
But then, per your/bishabosha’s interpretation, the text meant to be referring to the other meaning of “member” (i.e., methods, fields, etc., of a type). (Yes, that does seem to be the intent.)
The text should be disambiguated somehow.
I don’t know if there’s a word to put in front of “member” to clarify which kind of member the text means (e.g., corresponding to “set member” for the other kind).
Perhaps it would be clearer to add something like “(methods, etc.)” like this: “The members (methods, etc.) of an intersection type A & B are all the members of A and all the members of B .”
(The union-types page might have the same ambiguity.)
Yes, a contributed pull request improving the clarity would be welcome.
oh right, i might have been a bit spec/compiler brained here - where def/val/class etc are referred to as “members” of their outer scope,