Proposal: Implicit cast from property expression to get/set delegate?

[rossdempster]

Potential use case is as follows:

// Read documents from a document store. Multiple lookups are batched into
// a single database roundtrip, thus we can't await each individual call.
mapper.TryReadDocumentBatched<UserEntity>(source.UserId).SendTo(x => result.User = x);
mapper.TryReadDocumentBatched<UserEntity>(source.AssignedToId).SendTo(x => result.AssignedTo = x);
...
await mapper.FinishMappingAsync();

And the proposal would allow this:

mapper.TryReadDocumentBatched<UserEntity>(source.UserId).SendTo(result.User);
mapper.TryReadDocumentBatched<UserEntity>(source.AssignedToId).SendTo(result.AssignedTo);
...
await mapper.FinishMappingAsync();

There's not much to this. We're just recognizing the hidden set_XXX() method behind the property and allowing the compiler to generate a delegate if the target has a matching signature.

What the compiler is actually doing:

mapper.TryReadDocumentBatched<UserEntity>(source.UserId).SendTo(result.set_User);
mapper.TryReadDocumentBatched<UserEntity>(source.AssignedToId).SendTo(result.set_AssignedTo);
...
await mapper.FinishMappingAsync();

I think there's precedent for this kind of target matching with the existing expression trees vs delegate matching for expressions etc.

This is very minor syntactic change so probably not even worth the effort. It did seem neat though. I thought I'd mention it in case any other use cases come to mind. I think it could have potential uses in "fluent" APIs, especially if the compiler could generate a specially recognised class that contains both delegates.

SomeFluentApi
   .AddProperty(SomeClass.Name)
   .AddProperty(SomeClass.Age)
   .etc

The compiler could potentially map SomeClass.Name etc. to a built-in class:

class PropertyAccessor<TClass, TValue>
{
    Func<TClass, TValue> Getter { get; }
    Action<TClass, TValue> Setter { get; }
}

i.e. the signature of the fluent API's AddProperty method would be as follows:

FluentBuilder AddProperty<TClass, TValue>(PropertyAccessor<TClass, TValue> property);

This is a slight variant on my use case above. There would need to be both static and instance versions of this mechanic, with different delegate mappings.

Maybe even stick a PropertyInfo on there.

Just thinking out loud really. What do you think?

[jnm2]

I would love this! I think it's been suggested before to use the syntax someObj.Property.get and someObj.Property.set to create a delegate, which is almost better because you don't have to think about each of the two signatures to figure out what's going on when reading code. If would be great if both someObj.Property.get and SomeClass.Property.get worked, because they have different signatures and each is useful.

[svick]

A similar proposal for events: https://github.com/dotnet/roslyn/issues/298.

I agree that something like PropertyAccessor would be useful, but I don't like the proposed syntax. Code like someObj.Property already means something: getting the value of the property. I don't think we should add another meaning to that expression.

And the same issue applies to someObj.Property.get.

[TheUnlocked]

I like the general idea, but that particular syntax would run into issues here:

class Foo {
    Action<int> ExampleProperty {get; set;}
    public Foo(Action<int> prop) {
        ExampleProperty = prop;
    }
    public void Bar(Action<int> action) {
        action.Invoke(5);
    }
    // ...
}
// ...
Foo f = new Foo(x => Console.WriteLine(x));
f.ExampleProperty.Invoke(5); // Does this throw an error?
f.Bar(f.ExampleProperty); // Does this throw an error?

[rossdempster]

I tried this out with expression trees to see how it's handled already:

static void Thing(Func<int> func);
static void Thing(Expression<Func<int>> exp);

static void Main(string[] args)
{
    Func<int> func = () => 15;              // the duality is fine here
    Expression<Func<int>> exp = () => 15;   // the duality is fine here

    Thing(() => 15);                        // but this is an "ambiguous" error
}

@svick: The duality of the notation doesn't seem like a problem in practice. The intent can be clear from the usage (i.e. as with the two forms of () => 15 as above).

@TheUnlocked: Your two "does this throw an error?" examples:

1. I don't think so. Implicit casts don't work like that in general. (Saying that, this isn't technically an implicit cast, it's the compiler performing pattern matching - but I don't see why it would attempt pattern matching for no reason).
2. Good example. This is much more interesting! It reminds me of the duality of params (i.e. passing an array instead of a list of parameters). I think this is solved by PropertyAccessor instead of Action(Of T). The class doesn't exist at this time thus nobody has existing code that accepts it (i.e. the proposed syntax is non-breaking). In this case, I suggest it is an error if ambiguous like in the expression tree case.