Downcasting objects ignores explicit MapProperty instructions

[brutaldev]

• I have read the documentation, including the FAQ
• I can reproduce the bug using the latest prerelease version
• I have searched existing discussion and issue to avoid duplicates

Describe the bug
When defining MapProperty rules on a method that maps from a parent type to sub-type the generated code is a downcast and the MapProperty instruction is ignored. A real-world example where this was picked up is a class that encrypts items in its base class. When you need to convert it back to the base class the encrypted values need to be copied back into the base class properties unencrypted. MapProperty is used to instruct it to do this but the generated code does not include this instruction.

Declaration code

public class ComplexType
{
  public List<string> Strings { get; set; } = [];
}

public class AnotherComplexType : ComplexType
{
  public List<string> SameStrings { get; set; } = [];
}

[Mapper]
public static partial class MyMapper
{
  [MapProperty(nameof(AnotherComplexType.SameStrings), nameof(ComplexType.Strings))]
  public static partial ComplexType BrokenMapper(this AnotherComplexType source);
}

Actual relevant generated code

public static partial class MyMapper
{
    [global::System.CodeDom.Compiler.GeneratedCode("Riok.Mapperly", "4.1.1.0")]
    public static partial global::MapperlyInheritanceMapPropertyBug.ComplexType BrokenMapper(this global::MapperlyInheritanceMapPropertyBug.AnotherComplexType source)
    {
        return (global::MapperlyInheritanceMapPropertyBug.ComplexType)source;
    }
}

Expected relevant generated code

public static partial global::MapperlyInheritanceMapPropertyBug.ComplexType WorkingMapper(this global::MapperlyInheritanceMapPropertyBug.AnotherComplexType source)
{
  var target = (global::MapperlyInheritanceMapPropertyBug.ComplexType)source;

  // Use MapProperty instructions.
  target.Strings = source.SameStrings;

  return target;
}

OR

public static partial global::MapperlyInheritanceMapPropertyBug.ComplexType WorkingMapper(this global::MapperlyInheritanceMapPropertyBug.AnotherComplexType source)
{
  var target = new global::MapperlyInheritanceMapPropertyBug.ComplexType();
  target.Strings = global::System.Linq.Enumerable.ToList(source.SameStrings);
  return target;
}

Reported relevant diagnostics
None

Environment (please complete the following information):

• Mapperly Version: 4.1.1
• Nullable reference types: Enabled
• .NET Version: 9.0.0
• Target Framework: net9.0
• Compiler Version: 4.12.0-3.24572.7 (dfa7fc6b)
• C# Language Version: 13.0
• IDE: Visual Studio v17.12.3
• OS: Windows 11

Additional context
Using UseDeepCloning works correctly producing the following generated code:

public static partial class MyMapper
{
    [global::System.CodeDom.Compiler.GeneratedCode("Riok.Mapperly", "4.1.1.0")]
    public static partial global::MapperlyInheritanceMapPropertyBug.ComplexType BrokenMapper(this global::MapperlyInheritanceMapPropertyBug.AnotherComplexType source)
    {
        var target = new global::MapperlyInheritanceMapPropertyBug.ComplexType();
        target.Strings = global::System.Linq.Enumerable.ToList(source.SameStrings);
        return target;
    }
}

However, this applies to the entire Mapper class not just specific mapper methods and in complex mappers with dozens of types you would sacrifice reference copying performance across the board.

[latonz]

Thanks for reporting. Currently this is the expected behaviour, as Mapperly considers a cast as a "complete" mapping and doesn't apply any further mapping rules. I can see that there are use-cases for which additional configuration rules make sense, I changed it from a bug to a feature request 😊

[brutaldev]

The more I think about it and go over this with colleagues of mine, we seem to agree this violates POLA. If you've supplied mapping rules the expectation is that they are honoured. I think it's certainly a surprise when attributes are ignored.

The code in question was a conversion from AutoMapper that was quickly picked up as not working despite the correct code conversion being put in place. And not to say AutoMapper made all the correct assumptions about things, but if you supplied a FromMember rule it would certainly not ignore it.