Covariant / Covariance definition

[MaryaBelanger]

Probably not too critical, but in the soon to be released diagnostics for Extension Types, one mentions "type parameters used in a non-covariant position".

I searched dart.dev to explain "covariant positions", but didn't find an explicit "this is what covariance means and these are / aren't the positions".

Might be a matter of adding an explicit definition to the Glossary, or changing the covariant keyword section's wording slightly to explicitly say "Covariance is...".

I also think that covariant keyword section would probably be better suited somewhere else, like in the language tour, maybe the Types section? Or fitted in somewhere with the deconstruction of the Type System page we're planning.

[eernstg]

Covariant/contravariant/invariant positions are defined precisely in section 15.1 of the bleeding edge language specification, page 83++, here as source.

That's rather heavy reading, but it might work to have (1) conceptual description, rules of thumb, examples, and (2) a reference to the specification.

[MaryaBelanger]

Awesome, that helps a lot! Will definitely link to the spec and try a small, high-level summary for the glossary.

[parlough]

Speaking to the keyword location, I also think the current situation is not great. It's not super consistent or discoverable, but maybe that's slightly by design as it is not super common and it does cause a loss of some type safety.

I think the long term solution is to place it when overhauling our type system documentation, but if you feel it's better in the current type system page, I'd be fine with that for now too :)

It does however "fix a common type problem", so we should at least make sure a reference remains from the existing page.

[parlough]

@eernstg I was wondering if you'd be willing to add some initial definitions to the glossary (page, source) for these concepts in the context of Dart?

Even if not fully fleshed out, they would be quite helpful as a reference to point others to in various discussions and proposals, both in the site and otherwise.

[eernstg]

Sure! What's the best way to do that? Should I write a comment here with a draft proposal?

[parlough]

Thanks so much :D

If a comment would work best for you, that works! But I think a PR to update the glossary source page with your proposals would be best. That way we can comment on specific portions and the changes will be automatically staged.

We will eventually move to more structured YAML entries for glossary terms, but for now, I think a summary sentence (or two) followed by more details is sufficient. Those longer details can be as long as you need, with or without code snippets, external links, etc.

[eernstg]

Here's something: #6105.