rust-lang / rust-lang/nomicon

Suggestion to rewrite variance in fuction arguments explanation

Open
#394 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
CSS
Stars
2.3k
Forks
325
PR merge metrics
No merged PRs in 30d

Description

I have a hard time trying to understand variance in function arguments in the following chapter:

However, the same logic does not apply to arguments. Consider trying to satisfy:

fn handle_animal(Animal);

with:

fn handle_animal(Cat);

The first function can accept Dogs, but the second function absolutely can't.
Covariance doesn't work here. But if we flip it around, it actually does
work! If we need a function that can handle Cats, a function that can handle any
Animal will surely work fine. Or to relate it back to real Rust: if we need a
function that can handle anything that lives for at least 'long, it's perfectly
fine for it to be able to handle anything that lives for at least 'short.

The most confusing thing is what does it mean to "satisfy one function with the other"?

I'd suggest to rewrite this paragraph

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The requested passage is in src/subtyping.md, in the section explaining variance in function arguments. Read that paragraph and its surrounding examples first, focusing on clarifying what it means to satisfy one function requirement with another. Done means the explanation is rewritten so that relationship is understandable to readers unfamiliar with the terminology.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.