Update and fix the generic extension methods document and the RC1 release blog

[ShapelessCat]

• I update the extension-methods.md and the corresponding part in the 2021-02-17-scala3-rc1.md.
  The only if in this paragraph

  By contrast, type arguments matching type parameters following extension can be passed only if the method is referenced as a non-extension method

  is not right. Now it supports 4 different forms of call

• I update the extension-methods.md, and make it consistent with the corresponding part in the 2021-02-17-scala3-rc1.md.

• Change the level of headings in 2021-02-17-scala3-rc1.md.

  • About the level of headings:
    the markdownlint of my editor tells me we shouldn't use multiple top level headings in one file.
    I'm not sure if this follows our convention for the release blog article. If we want to keep using multiple top level headings, please tell me, and I can revert this change.

[odersky]

is not right. Now it supports 4 different forms of call, as an extension method or not:

Strictly speaking the "only if" is correct. The other two forms of call parameterize the argument to the extension method, not the method itself. But maybe that's hair-splitting. I like the proposed alternative.

[ShapelessCat]

Can we merge this one?

[anatoliykmetyuk]

is not right. Now it supports 4 different forms of call, as an extension method or not:

Strictly speaking the "only if" is correct. The other two forms of call parameterize the argument to the extension method, not the method itself. But maybe that's hair-splitting. I like the proposed alternative.

I do not think this is hairsplitting, I think this is pretty important. We are parameterising precisely the argument and not extension method. It is the same thing as to say, “there are two ways to provide type parameters to a method, f[String](x) and f(x: String)”. Which can lead to wrong results in case of more complex type inference. E.g.:

def f[T](x: T, y: T): T = y
val x = "foo"
val y = 10

f[String](x, y)  // error
f(x: String, y)  // no error, inferred type is Any

We should not mislead people in our docs.

[anatoliykmetyuk]

(see above comment)

[bishabosha]

Looks good, this change should be applied to the blog also.

[ShapelessCat]

is not right. Now it supports 4 different forms of call, as an extension method or not:

Strictly speaking the "only if" is correct. The other two forms of call parameterize the argument to the extension method, not the method itself. But maybe that's hair-splitting. I like the proposed alternative.

I do not think this is hairsplitting, I think this is pretty important. We are parameterising precisely the argument and not extension method. It is the same thing as to say, “there are two ways to provide type parameters to a method, f[String](x) and f(x: String)”. Which can lead to wrong results in case of more complex type inference. E.g.:

def f[T](x: T, y: T): T = y
val x = "foo"
val y = 10

f[String](x, y)  // error
f(x: String, y)  // no error, inferred type is Any

We should not mislead people in our docs.

Thanks! @anatoliykmetyuk

I think I misunderstood the document, and I wasn't clear about the concepts.
Now I understand what you mean.

I just update this PR and revert the change about generic extension methods in 2021-02-17-scala3-rc1.md.
Now the only change in extension-methods.md is that I modify it to make it consistent with the corresponding part in 2021-02-17-scala3-rc1.md.

[anatoliykmetyuk]

What's the motivation behind using heading level 2 instead of 1 and leaving a newline?

[michelou]

@anatoliykmetyuk I invite you to look at the Google Style Guide, for instance the section Add spacing to headings.
IMO the best choice would be to adher to an existing style guide or (at least) to agree on a minimal set of rules which work both with Scaladoc and with tools such as Pandoc (see PR #11257).

[anatoliykmetyuk]

Why 3rd header level here? In all blog articles, this item is a top-level header.

[ShapelessCat]

@anatoliykmetyuk Fixed.