Proposal: calling same method with 'this' and 'base'

[lachbaer]

I would like to propose calling the same method name by re-using this and base keywords.

[Update:] The initial proposal has been withdrawn by the author. But the second part shall still stand.

Updated Proposal

For void returning methods a call to another overload in the same (this) or base class can be made by using the same syntax as for constructors:

public void OnHandleEvent(EventArgs event) : base(event)
{
  /* do own processing */
}

...for : this(...) respectively.

If I haven't overseen anything it would not conflict with any other use of this or base and be consistent with the constructor syntax.

Benefits

• better reading, because own method name needn't be repeated as first statement
• makes the well known c'tor syntax available to other methods
• easier refactoring, because calling of other overloads is easily spotted

Initial proposal (withdrawn)

Let's say you have a recursive funktion

public int Fibonacci(int number)
{
    if (number <= 1)
    {
        return 1;
    }
    else
    {
        return this(number - 2) + this(number - 1);  // calls the same function
    }
}

When you are going to rename the function, you don't have to rename the occurences within the function. (I know that IDEs can help here... )

Another use would be to call an overloaded function:

public int Skip(int steps) => _counter += steps;
public int Skip() 
{
    return this(1);  // calls this.Skip(1)
}
// or shorter
public int Skip() => this(1);

The same should be true for calling the base class, e.g. for the following common pattern

public void OnHandleEvent(EventArgs event)
{
  base(event); // calls base.OnHandleEventArgs(event)
  /* do own processing */
}

Also for void returning methods the syntax could be extended like for constructors

public void OnHandleEvent(EventArgs event) : base(event)
{
  /* do own processing */
}

...for : this(...) respectively.

If I haven't overseen anything it would not conflict with any other use of this or base and be consistent with the constructor syntax.

[YaakovDavis]

This will collide with the proposed functors.
Even without functors, this is IMO confusing.

[scottdorman]

For reference, the functors proposal in the Roslyn repo (dotnet/roslyn#14731) has been closed in favor of it's equivalent one (#95) in this repo.

[lachbaer]

The ': this/base' syntax wouldn't collide.
How about prepending static., or appending?

public int Skip() => static.this(1);
// vs.
public int Skip() => this.static(1);  // or base.static(1)

[scottdorman]

How about prepending static., or appending?

That makes the syntax even messier and more confusing, in my opinion.

[YaakovDavis]

How is
public int Skip() => static.this(1);
better than
public int Skip() => Skip(1);?

(Not that the Skip() in itself is a good name. I'll call it SkipOne()).

[lachbaer]

I admit that #95 would be much more useful! And it conflicts partly with the syntax of this proposal.

But I still think that there is meaningful use in not repeatedly stating the functions own name again. Like in the use case I had with my dozens of classes that I had to change manually.

[scottdorman]

@lachbaer

Like in the use case I had with my dozens of classes that I had to change manually.

Wouldn't a refactor|rename operation have worked for that?

[lachbaer]

@scottdorman

Wouldn't a refactor|rename operation have worked for that?

Yes, it probaby would have but with more clicks. And I want to quote myself:

But I still think that there is meaningful use in not repeatedly stating the functions own name again.

I withdraw the part of this proposal reagarding in-method-body-calls to this(...) and base(...).

There are currently no real comments on the 'constructor-like' syntax I described here. In my eyes it has a consistend style and could help to write compacter code in case of overloading and overwriting.

[lachbaer]

Updated the initial proposal.

[CyrusNajmabadi]

If I haven't overseen anything it would not conflict with any other use of this or base and be consistent with the constructor syntax.

Constructors need this as the very first thing they have to do is delegate as appropriate. That's not the case for methods at all. Methods may call an overridden member anywhere in their execution block (including multiple times).

Providing syntax to special case precisely one of these seems incomplete.

[lachbaer]

This is only about readability and shortening, exactly as expression syntax for methods is (for users):

void CalculateSumAndRaiseEventWithResult(int[] values) : base(values)
    => RaiseChildsAdditionalCompletedEvent();

is simply easier and shorter to read and write than

void CalculateSumAndRaiseEventWithResult(int[] values)
{
    base.CalculateSumAndRaiseEventWithResult(values);
    RaiseChildsAdditionalCompletedEvent();
}

Just an idea, calling a value returning function results in an additional parameter

int CalculateSumAndRaiseEventWithResult(int[] values) : int result = base(values)
{
    RaiseChildsAdditionalCompletedEvent(result);
    return result;
}