Virtual and Abstract Local Functions

[AdamSobieski]

Hello. I would like to broach for discussion a hopefully beneficial idea for the C# programming language. I propose that local functions could be virtual or abstract.

Some syntax ideas are presented, in these regards. In particular, a syntax idea is presented towards being able to express the overriding of a method's local function.

public class Instance1
{
    public void Invoke(Context context)
    {
        virtual void StepOne(int n) { }
        virtual void StepTwo(int n) { }
        virtual void StepThree(int n) { }

        StepOne(context.x);
        StepTwo(context.y);
        StepThree(context.z);
    }
}

public class Instance2 : Instance1
{
    override void Invoke(Context context).StepTwo(int n)
    {
        // note that developers can access and utilize both of the variables "context" and "n" here.
    }
}

Above, the method Invoke provides developers with a type of contract with respect to its functionality while allowing some or all of its steps to be overridden, e.g., StepTwo.

In the event of interest, I could write up a more detailed explainer on these ideas.

Any thoughts on these ideas? Thank you!

[HaloFour]

I dislike this. Local functions don't exist outside of the scope in which they are defined. They aren't members to invoke within the current type, let alone derived types. This is a scenario already solved perfectly fine by defining proper protected members within the current type, which allows the derived type to override them.

[333fred]

Indeed. I don't see any motivation as to why I would want to override these. This is what protected virtual members are for.

[HaloFour]

Method-scoped protected members? :D

[AdamSobieski]

If I understand correctly, the recommended approach for the example scenario involves utilizing protected virtual methods, resembling:

public abstract class Procedure
{
    public abstract void Invoke(Context context);
}

public abstract class Instance1 : Procedure
{
   public sealed override void Invoke(Context context)
   {
       StepOne(context, context.x);
       StepTwo(context, context.y);
       StepThree(context, context.z);
   }

   protected virtual void StepOne(Context context, int n) { ... }
   protected virtual void StepTwo(Context context, int n) { ... }
   protected virtual void StepThree(Context context, int n) { ... }
}

public class Instance2 : Instance1
{
    protected override void StepTwo(Context context, int n) { ... }
}

[333fred]

Yes, that's correct. It exposes that these members actually exist, which local functions are specifically designed to not do. Local functions are an implementation detail of a specific method; if you want to override that, well, that's no longer an implementation detail of a specific method, but is instead an implementation detail of the type itself.

[HaloFour]

Also, the referenced discussions are about overloading, not overriding.

[AdamSobieski]

Thank you and I updated the initial post per your advice, removing those hyperlinks to discussions which were about overloading, not overriding.

[CyrusNajmabadi]

I'm not seeing a motivating scenario here. Could that be added?

[AdamSobieski]

Yes. I can add that into a revised initial post, upcoming. I thought of these ideas while brainstorming about procedural knowledge, inheritance between procedures, adding steps to / removing steps from / modifying steps of / overriding steps of procedures to create resultant new procedures, and dependency graphs between procedures and their implementations.

[CyrusNajmabadi]

@AdamSobieski all that sounds like modeling your procedure steps as classes with virtual methods, and then just overriding those classes.