New flag ExhaustSource

[nimatrueway]

Checklist

• I read the documentation at https://chimney.readthedocs.io/ and checked that the functionality doesn't exist
• I checked the https://github.com/scalalandio/chimney/issues and haven't found the feature already requested reported
• I confirmed that the request is not related to functionality that was deprecated: lifted transformers (TransformerFs) or unsafeOption flags
• I believe that this is actual feature request, rather than a question how to use existing features

Describe the desired behavior

case class RequestModel(name: String, age: Int)
case class DatabaseModel(name: String)

val toDatabaseModelT =
  Transformer
    .define[RequestModel, DatabaseModel]
    .enableExhaustSource // proposed flag, results in compile error: `age` is not used
    .withSourceFieldIgnored(_.age) // proposed new utility method, fixes the compile error
    .buildTransformer
}

Thanks for the great library!

I'd propose that we add a new flag ExhaustSource to the transformer that emits compiler error if not all source fields were mapped to a field in the destination model. This is useful when you'd like to enforce a 1:1 mapping between source and destination field.

Use case example

As the From model evolves you'd like to rely on the compiler to tell you what new fields need too be added to the To model

• When From is API request model and To is database persistence model
• Same but with database model as From and response model as To

How it relates to existing features

Preserves the existing behaviour. The new feature just adds an stricter check if enabled.

Additional context

As a workaround in our company we build another transformer but in the opposite direction and never use it, it is
added only to emit compile error if an extra field of From is not used. This has led to significant redundant code which would not be needed if this feature existed.

If the maintainer sanity checks this idea, I might give it a shot myself as a hobby project.

[MateuszKubuszok]

I'm afraid it might be a bit more complex than just boolean flag since just OTOH the valid behavior could be:

• ignore unused source fields,
• fail on any unused source fields in top-level source value, ignore unused in nested transformations
• explicitly allow a list of unused source values, require all the others to be used
• explicitly allows a list of fields to use, require all the others unused

and for subtypes (because they can only be unused on the target side)

• ignore unused enum subtypes
• fail on any unused enum subtype
• ...

Unfortunately, if one makes it a boolean flag, it's really hard to change the API later in a binary-compatible way. Especially, since we can assume upfront that the list of possible behaviors is not fixed and it will only increase if #115 gets implemented.

Technically, it's the same as #248, so we can continue the discussion there.