[Proposal] Auto-fluent interface for void-return methods

[Remleo]

Hi all!

Suppose we have Entity:

public class Entity
{
    public void One() { ... }
    public void Two() { ... }
}

If need to call both methods, than

var entity = new Entity();
entity.One();
entity.Two();

I propose adding syntactic sugar to make possible call void-return mehtods in chain:

new Entity().One().Two();

I think the Compiler can automatically transform the chain entity.One().Two() to entity.One(); entity.Two();.

In lambda expressions:

...Configure(entity => entity.One().Two());

// instead of
...Configure(entity => {
     entity.One();
     entity.Two();
});

More complex case:

    public class BaseBuilder
    {
        public BaseBuilder AddRule()
        {
            return this;
        }
    }

    public class CustomBuilder : BaseBuilder
    {
        public CustomBuilder AddCustomRule()
        {
            return this;
        }
    }

Using:

((CustomBuilder) ((CustomBuilder) new CustomBuidler().AddRule()).AddCustomRule().AddRule()).AddCustomRule();

We must convert explicitly to CustomBuilder to call AddCustomRule() after each AddRule().

With auto-fluent syntax sugar it makes it much more easier:

    public class BaseBuilder
    {
        public void AddRule()
        {
        }
    }

    public class CustomBuilder : BaseBuilder
    {
        public void AddCustomRule()
        {
        }
    }

// Pretty chaining
new CustomBuidler().AddRule().AddCustomRule().AddRule().AddCustomRule();

And more usefull usage in extension-methods:

    // Interfaces
    public interface IBaseBuilder
    {
        List<string> Rules { get; }
    }
    public interface ICustomBuilder : IBaseBuilder
    {
        List<string> CustomRules { get; }
    }

    // Implementations
    public class BaseBuilder : IBaseBuilder
    {
        public List<string> Rules { get; } = new List<string>();
    }

    public class CustomBuilder : BaseBuilder, ICustomBuilder
    {
        
        public List<string> CustomRules { get; } = new List<string>();
    }

    // Extension methods
    public static class BuilderExtensions
    {
        public static IBaseBuilder AddFooRule(this IBaseBuilder builder)
        {
            builder.Rules.Add("Foo");
            return builder;
        }

        public static IBaseBuilder AddBarRule(this IBaseBuilder builder)
        {
            builder.Rules.Add("Bar");
            return builder;
        }

        public static ICustomBuilder AddCustomFooRule(this ICustomBuilder builder)
        {
            builder.CustomRules.Add("Bar");
            return builder;
        }
    }

Instead of this:

((ICustomBuilder)((ICustomBuilder) ((ICustomBuilder) new CustomBuilder().AddFooRule()).AddCustomFooRule().AddBarRule())
                .AddCustomFooRule().AddFooRule()).AddCustomFooRule();

much more pretty syntax:

new CustomBuilder().AddFooRule().AddCustomFooRule().AddBarRule()
                .AddCustomFooRule().AddFooRule().AddCustomFooRule();

if make extension-methods void-return:

    public static class BuilderExtensions
    {
        public static void AddFooRule(this IBaseBuilder builder)
        {
            builder.Rules.Add("Foo");
        }

        public static voidAddBarRule(this IBaseBuilder builder)
        {
            builder.Rules.Add("Bar");
        }

        public static void AddCustomFooRule(this ICustomBuilder builder)
        {
            builder.CustomRules.Add("Bar");
        }
    }

Thanks!

[MgSam]

You're proposing to change silently the meaning of void. I prefer void to mean exactly what it currently means. If you want a fluent pattern, return this at the end of your methods instead of void.

I suspect a feature you may be interested in is covariant return types. This would allow you to specify more specific types in subclasses.

[alrz]

Note that fluent methods don't always return this, depending on the context you might want a different builder, so this seems to fail to cover the very use case it aims to address.

PS: Also, as a syntactic sugar, this messes with typecheck, you should never mess with typecheck.

[jnm2]

Dupe: #577
Related: #311

[Remleo]

dotnet/roslyn#8947
and
dotnet/roslyn#16961