Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed types-variance.md contravariant example code comment #2938

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

still-dreaming-1
Copy link

Fixed the second code comment for the last example just before the summary. The words "Book" and "Buyable" needed to be swapped. This makes it consistent with how the first comment uses the term "expected", where "expected" refers to the type you see in the following line of code. The first code comment is referring to the return type in the next line of code. The second comment is referring to the parameter type in the following line of code. Therefore, in the second code comment, "Book" is what is "expected" (by the h type), and "Buyable" is what is "provided" by the f parameter type.

Fixed the second code comment for the last example just before the summary. The words "Book" and "Buyable" needed to be swapped. This makes it consistent with how the first comment uses the term "expected", where "expected" refers to the type you see in the following line of code. The first code comment is referring to the return type in the next line of code. The second comment is referring to the parameter type in the following line of code. Therefore, in the second code comment, "Book" is what is "expected" (by the h type), and "Buyable" is what is "provided" by the f parameter type.
@still-dreaming-1
Copy link
Author

still-dreaming-1 commented Dec 20, 2023

If I am mistaken about how these terms are used, then the first code comment needs to be changed. Either way, the current code comments are inconsistent and confusing. The way they currently read sounds like it is applying covariant logic to both explanations, even though the parameter/consumer type is and should be contravariant and the return/producer type is and should be covariant.

@joroKr21
Copy link
Member

expected here refers to the definition of f:

val f: Function[Buyable, Buyable] = b => b

So it both expects and returns a Buyable.
Does that make more sense now?

@joroKr21
Copy link
Member

joroKr21 commented Dec 21, 2023

You can try to extend the sentence with the verb used:

// OK to return a Buyable where an Item is expected **to be returned**
// OK to provide a Book where a Buyable is expected **to be provided**

@still-dreaming-1
Copy link
Author

still-dreaming-1 commented Dec 21, 2023

It seems to me that "expected" should consistently refer either a type in f or a type in the line of code following the comment (a type in g or h). I don't think it is good for the meaning of the term "expected" to change in these two comments.

Here is the complete example with both comments:

val f: Function[Buyable, Buyable] = b => b

// OK to return a Buyable where a Item is expected
val g: Function[Buyable, Item] = f

// OK to provide a Book where a Buyable is expected
val h: Function[Book, Buyable] = f

The first comment is comparing the return type of g to the return type of f. If "expected" refers to the type in g it is correct, but if it refers to the type in f it is wrong.

The second comment is comparing the parameter type of h to the parameter type of f. If "expected" refers to the type in h, it is wrong, but if it refers to the type in f it is correct.

I don't think swapping the meaning of "expected" between these two comments is helpful because it makes it sound like a line of reasoning rather than a statement of what is or how the language works. Then it can become confusing because it sounds like it is using covariant reasoning to defend contravariant types by always putting the more specific type first. This could imply that the reason it makes sense is because a "Buyable" is an "Item" (which intuitively makes sense), and that "Book" is a "Buyable" (which also intuitively makes sense, and thus is misleading).

@still-dreaming-1
Copy link
Author

Perhaps the types should be flipped in the first comment instead of the second. Also, changing the word "OK" to "Allowed" would go even further in the direction of making these sound like statements of what is / how it works, rather than a line of reasoning.

@SethTisue
Copy link
Member

@joroKr21 care to respond further?

@joroKr21
Copy link
Member

joroKr21 commented Feb 14, 2024

Well I think it's precisely the variance that determines in which direction to apply "expected". Let's say we expect a type F[A] and provide a type F[B]

  • if F[+_] is covariant, we expect that A <:< B
  • if F[-_] is contravariant we expect that B <:< A
  • if F[_] is invariant we expect that A =:= B

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants