Initializer Conversion

[KirkMunro]

We use AutoMapper at work, and while the value in the simplified mappings is easy to see, I'm not at all fond of the implementation which leaves error discovery to runtime, so I started tinkering with how mapping functionality could be added to the C# language itself, and I came up with a new Initializer Conversion syntax.

The use case for this is simple: provide a way to convert (map) between two types that do not have a supported converter, using inline initializers.

Here's an example that illustrates the syntax I'd like to propose:

var convertedThing = thing as ConvertedThing
{
     // These properties are left as default (maybe these two lines are entirely unnecessary?)
    Prop1 = default,
    Prop2 = default,
    // These properties have mapped assignments from the thing instance
    Prop3 = (t => t.OtherProp3),
    Prop4 = (t => t.Prop4.ToString()),
    // These properties have unmapped (direct) assignments to expressions
    Prop5 = foo,
    Prop6 = await GetBarValueAsync(),
    // All remaining properties are automapped by name
    _ = _,
};

For the last line of the initializer, I had also considered _ = auto, (new auto keyword) or _ = (t => _) as a way to indicate that remaining properties should be automatically mapped from source properties with the same name. I'd like to hear other ideas from anyone who doesn't like _ = _ as a way to indicate that remaining mapping should be done automatically.

If you only wanted to map a few properties, and leave everything else as default, you could do this instead:

var convertedThing = thing as ConvertedThing
{
    // These properties have mapped assignments from the thing instance
    Prop1 = (t => t.OtherProp1),
    Prop2 = (t => t.Prop2.ToString()),
    // These properties have unmapped (direct) assignments to expressions
    Prop3 = foo,
    Prop4 = await GetBarValueAsync(),
    // All remaining properties are left as default (maybe this line is entirely unnecessary?)
    _ = default,
};

If your properties all map by name, you would simply define the Initializer Conversion like this:

var convertedThing = thing as ConvertedThing { _ = _ };

Initializer Conversion mappings can be reused simply through methods.

The value in such a language feature as I see it would be:

1. Elimination of a lot of boilerplate mapping code that is otherwise required even if property names are the same (this is the key value add for this Initializer Conversion syntax vs using new with initializers).
2. Required properties are respected, with compilation errors raised when something that is required is not initialized as part of the initializer conversion.
3. Invalid mappings would lead to compilation errors.
4. Object construction remains simplified, while using a familiar initializer syntax.
5. Unlike Automapper, there are no hidden mappings or implicit conversions with this as a language feature.
6. Also unlike Automapper, since nothing is hidden, the mapping logic can be seen as you step through code in the debugger.

This new syntax significantly simplifies object mappings in C# like AutoMapper does without losing the benefits of compilation errors.

[pinkfloydx33]

We also use AutoMapper and I can agree that sometimes there's a little too much "magic" going on that isn't obvious until runtime. Debugging stinks and things like required properties don't work the way you'd want them to.

That said, this feels like too much of a niche case. Sure a lot of folks do object mapping, and we'd definitely benefit from the feature... to a point. We have a lot of customized mapping logic that I'm not sure a language feature could support in the general case. AM also supports projecting expressions, and I doubt a language feature would include that, meaning you'd still need some other tool.

On the one hand it somewhat feels like an extension of withers that could apply to arbitrary types which would certainly be useful. I'm not sure if that can work in the general case; at the very least I'd expect issues when dealing with types in external assemblies. On the other hand I feel like it's too specialized and doesn't belong in the language. Basically: I'm on the fence but leaning to the "no" side.

We've started looking at Source-generated mapping logic. There's libraries like Mapperly that look like they can get the job done pretty well while supporting a lot of the features you yearn for. In my head I can hear Cyrus and others saying "use a source generator" that can be customized to your needs. I feel like that's where this request will ultimately land and I don't think I disagree.

[KirkMunroSagent]

It's been a few years since I posted this suggestion, but it keeps coming back to me. I've been preferring initializers over constructors for POCO objects, and using required and {get; init;} for property definitions in those objects to ensure that they remain immutable once they are initialized.

The problem is, if you use something like AutoMapper, and you map one object type to another, where you want to ignore certain properties in the destination because they will be assigned independently from the object mapper, well that prevents you from using init for the setters because you have to assign those values after the object is initialized. I can switch back to constructors of course, but for POCO objects where I'm just mapping data and possibly extending it or combining it with other data for use in my application, and where I like to preserve objects in their original state, I really dislike constructors for this, especially if I want to make an async call to get the value that is to be assigned to the destination object.

The proposal above really helps in this regard, because I'm able to make async calls and perform assignments, all as part of initialization code for my object, without needing to do a bunch of other boilerplate code around it.

Anyway, I'll go look at Mapperly again, but since this hit me again today for the umpteenth time I figured I should look up this old suggestion and add a comment to it.

I looked at Mapperly again, and I still find shortcomings, particularly because I can't use init for setters with anything that falls outside of a property-to-property mapping. Defining mapping logic as an initializer is a really nice value add from my perspective.