Policy for checking which fields were used for transformation

[MateuszKubuszok]

Some users would find it useful to be able to fail compilation if some/all fields from source were not used during derivation. Example of such thing was asked in this StackOverflow question: https://stackoverflow.com/questions/73927120/chimeny-scala-validate-source .

Such feature was implemented in ducktape so alternative libraries already decided that it is worth providing.

We could consider adding some/all of the setting:

• .requireSourceFieldsUsed
• .requireSourceFieldsUsed(_.fieldA, _.fieldB, _.fieldC)
• .requireSourceFieldsUsedExcept(_.fieldA, _.fieldB)
• .requireTargetSubtypesUsed
• .requireTargetSubtypeUsed[SubType]
• .requireTargetSubtypeNotUsed[SubType]

[arainko]

Just to clarify, the thing implemented in ducktape is only applicable to the Field.allMatching config option, where it'll fail to compile if you pass in a case class that matches none of the destination fields (but only for the case class passed to this config option) like this:

test("Field.allMatching reports a compiletime failure when none of the fields match") {
    final case class Source(int: Int, str: String, list: List[String])
    final case class FieldSource(int: Long, str: CharSequence, list: Vector[String])

    assertFailsToCompileWith {
      """
      val source = Source(1, "str", List("list-str"))
      val fieldSource = FieldSource(1L, "char-seq", Vector("vector-str"))
      source.into[Source].transform(Field.allMatching(fieldSource))
      """
    }("None of the fields from FieldSource match any of the fields from Source.")
  }

But it doesn't affect other parts of derivation, so you'd be the trailblazers here ❤️

[MateuszKubuszok]

We could 😉 But it would be seriously helpful to know more about use cases of this feature. I saw some options named "policy" in Java's MapStruct but I have no idea what users could find useful, so any feedback about this is welcome!

For now we are mostly adding bugs and ideas to backlog to keep tabs on them, since we have a few things already planned (#239) and they will take some time 😄

[SevDan]

There is a use case for policies in systems integrations with verbose and huge APIs (100-500 properties in single method/dto) when you want continuosly update their version in your application, such as legacy SOAP services. So, you can have compile time error for any unhandled changes with precise policy for the important parts and ignore unimportant ones. This is probably the main reason to use java's mapstruct in java or kotlin