PEP 695: Fix/improve syntax & content of Language Survey section

[KotlinIsland]

This fixes up some of the inaccuracies in the 'Language Survey' section of the pep and adds a couple more languages.

• Related to PEP 695: Introduce in and out keywords for specifying variance #2724

[CAM-Gerlach]

Its up to @erictraut and @gvanrossum on the content, but I had some minor syntactic and textual fixes.

[gvanrossum]

@erictraut For you to review.

[erictraut]

Thanks for the edits and corrections. Just one small nit, but overall looks good to me.

[erictraut]

Readability was not the motivation for adding this capability. I meet often with the TypeScript team, and I'm very familiar with their motivations and the debates that led to their (reluctant) decision to add this capability.

[KotlinIsland]

It wasn't a motivation, but my edit here was based on information from the documentation

[KotlinIsland]

Could you provide some references for these reasons? Reading the pr microsoft/TypeScript#48240, it seems to lead with positive motivations and nothing negative that I can see:

Indeed, when generic type instantiations are related structurally, variance annotations serve no purpose. This is why TypeScript strictly doesn't need variance annotations. However, variance annotations are useful to assert desired type relations of their subject generic types.

[erictraut]

This information comes from direct conversations with Anders Hejlsberg, Ryan Cavanaugh, and Daniel Rosenwasser, the leads on the TypeScript team. I've discussed the arguments you've raised about variance. Here's how Daniel summarized their advice:
"our perspective is that ideally we wouldn't have added [explicit] variance if we didn't need to"

[Noratrieb]

Hi, I found this PR and wanted to add something about variance in Rust: As mentioned already, Rust doesn't have classic type subtyping but only for lifetimes. But, this still means that variance matters in Rust (because types can contain lifetimes), and there is a certain variance associated with every type parameter. Variance is always inferred by looking at the usage at the declaration site. So for example, if T is stored a normal owned value, it will be covariant. If it's stored behind a mutable reference, it will be invariant.

While the language itself does not provide any way to annotate the variance directly, you can control the variance manually by using the type in specific ways. There is a zero-sized-type called PhantomData<T> in the standard library, which can be used get a specific variance for a type.
For example

struct Cov<T> {
  _marker: PhantomData<fn(T) -> T>, // a function pointer where T is the input and output, 
}

will make T invariant.

This is also why an unused generic parameter is a compiler error in Rust, since it cannot possibly infer a variance for it.

[erictraut]

@KotlinIsland, could you please address the feedback from @Nilstrieb before this PR is merged?

[KotlinIsland]

@KotlinIsland, could you please address the feedback from @Nilstrieb before this PR is merged?

@erictraut I've added an example usage of lifetime subtyping to the rust section.

[erictraut]

I'm in favor of merging this version. I have another large round of changes to the PEP that I'm actively working on, and I'd prefer to get this merged in now to avoid merge conflicts.

[CAM-Gerlach]

Scanning the source and preview, the changes are to non-normative sections, improve the syntax and rendering of the PEP (with no obvious regressions), the content is approved by the PEP author and there are no other clear defects, so ✔️ from a PEP editor perspective, thanks.

[CAM-Gerlach]

Going ahead and merging per the preference of the PEP author, and the deference of such by the PEP sponsor. Thanks @erictraut and @KotlinIsland