Jonas Nyrup

I'm fine adding it. We should _perhaps_ document that the failure message will be slightly inferior to using `Excluding(e => e.Name == "Parent" || e.Name == "Children")`. To sum up:...

> > Slightly inferior failure message > > Why is that? Because of the string-based member matching? If so, let's see when the PR arrives if we can tweak that...

I'm perhaps missing something, but I don't see why it doesn't apply to `options.ExcludingMemberNames("Parent", "Children")`? ```cs ExcludingMemberNames("Parent", "Children"); static void ExcludingMemberNames(params string[] excludedMemberNames) => Excluding(member => excludedMemberNames.Contains(member)); static void Excluding(Expression...

Roger. This also makes this proposal much more appealing to me, as it can now improve the failure message from: ``` Exclude member when ((e.Name == "Parent") OrElse (e.Name ==...

@Xceed-DelvaJB Do you want to pick this up? Otherwise I can take it from here.

> If it's ok, I'd like to complete it. Absolutely fine.

I think a challenge is to find a definition of "complex" that's intuitive to most and not only applies to a single user's case. E.g. when I hear "primitive types",...

`Decimal`, `Half` and [`Complex`](https://learn.microsoft.com/en-us/dotnet/api/system.numerics.complex?view=net-9.0) are other examples of BCL value types that returns `false` for `Type.IsPrimitive`.

> My thinking is to allow the user to decide what is complex or not by supplying a callback that makes these decisions. We currently have a public overload of...

> Is that an approval [@jnyrup](https://github.com/jnyrup) ? It wasn't. What I showed was that the proposed definition of "complex" can be expressed and excluded via the current API. So we...