Local Extension Method

[RealmPlume]

Since we have local function.
why shouldn't we take the "Local Extension Method"？
it like where we use |> in F#:

int Foo(int value) {

    int Add10(this int x) => x + 10;

    int Sub3(this int x) => x - 3;

    return value
         .Add10()
         .Sub3();

}

[DavidArno]

Please could you fix your markdown formatting, as it makes your code hard to write read. Just wrap the code like this:

```cs
code
```

Aside from that, this seems like a sensible suggestion.

[svick]

Previous discussion: #799.

[jnm2]

@DavidArno hard to read, maybe?

[DavidArno]

@jnm2,

Yep, that too! 😀

[jcouv]

Tagging @agocke

[zspitz]

(Copying the relevant discussion from #1565)

@jaredpar commented on the discussion for local functions:

@TKharaishvili local extension method sis something we've considered but at this point don't have firm plans for. I think we'd need to see compelling scenarios to add the complexity to member lookup here.

Extension methods solve a couple of problems:

1. Adding behavior to a type that's not a part of it's declaration
2. Making the behavior discoverable by allowing the behavior to have member level syntax

In the case of local functions there is no discovery issue. The behavior is right there in the same method that you are editing. Can't even use partial tricks to put it into a different file. Hence it would seem to not have as much value as normal extension methods.

@TKharaishvili replied:

The benefits of [local extension methods] being method chaining and the fact that it reads better.

[zspitz]

Today I've been in a situation where local extension methods would be useful. This is the code I've written without local extension methods:

// using NodaTime;
// using System.Globalization;

public class AppliedZoneResult {
    public string? Instant1 { get; set; }
    public string? Instant2 { get; set; }
    public AppliedZoneResult(LocalDateTime local, DateTimeZone dateTimeZone) {
        string toInstantString(ZonedDateTime x) => x.ToInstant().ToString("g", CultureInfo.InvariantCulture);

        try {
            Instant1 = toInstantString(local.InZoneStrictly(dateTimeZone));
        } catch (AmbiguousTimeException ambiguousTimeException) {
            Instant1 = toInstantString(ambiguousTimeException.EarlierMapping);
            Instant2 = toInstantString(ambiguousTimeException.LaterMapping);
        } catch (SkippedTimeException) {
            // intentionally blank
        }
    }
}

I think the flow from local or ambiguousTimeException to the final string is much easier to see and understand using an extension method:

public AppliedZoneResult(LocalDateTime local, DateTimeZone dateTimeZone) {
    static string toInstantString(this ZonedDateTime x) => x.ToInstant().ToString("g", CultureInfo.InvariantCulture);

    try {
        Instant1 = local.InZoneStrictly(dateTimeZone).toInstantString();
    } catch (AmbiguousTimeException ambiguousTimeException) {
        Instant1 = ambiguousTimeException.EarlierMapping.toInstantString();
        Instant2 = ambiguousTimeException.LaterMapping.toInstantString();
    } catch (SkippedTimeException) {
        // intentionally blank
    }
}

but the logic of toInstantString is extremely localized to this specific area of the code; it's appropriate to limit the scope to within this constructor.

[Pzixel]

Is it possible to extend any instance method to a static one that takes a "this" reference as a first argument. So instead of

10.ToString()

I could write

int.ToString(10)

And vice versa. I think you can argue with an example of dual static-instance method that probably will break with this change so your answer will be "no" but I already typed all this so probably I'll leave this comment here.

[Happypig375]

@Pzixel That is not how extension methods work. Your proposal is different from this suggestion.