@ysbaddaden @RX14 I understand your concern that this bloats JSON.mapping and YAML.mapping a bit, but this bloat is very tiny in code and it's an optional feature (if you don't use it you don't need to learn it, and if you need it, it's there).

The nice thing about this is that you retain type safety and you keep the information of which keys were present in the original JSON. You can of course use JSON::PullParser or JSON.parse, but that is more tedious and less type-safe.

As a comparison, see this answer for how to do it in Go: you basically have to map the field to the raw bytes that came in the JSON, and then you have to parse it again... so you lose type-safety, and it's more tedious. I think it's nice if there's a built-in way to do it in the standard library.

As for a real use case: imagine an HTTP endpoint that accepts updates to an object. The client can specify which fields to update, and to clear a field sends {"field": null}. You have to know whether the field came to reset it. Right now there's no easy/elegant way to do it.

(but of course, like every PR since a few weeks ago, this has to be accepted by a few members, so my opinion alone doesn't count anymore: and that's very good)

IMHO this is too much, but I don't use X.mapping myself, and since there are valid use cases, then it's acceptable.

I can see the usecase much more clearly now, so yes it's a 👍 from me. Would be nice if there was a cleaner way to do this but there probably isn't unless we implement custom attributes and I have my own reservations about slinging around too much metadata.

Is there really a need for another option if it's only usable with nilable: true? Wouldn't be sufficient to include <field>_present? accessor when nilable option is set?

Yes, we need another option just because we have default option (that allowed without nilable too).

And presence option also has bool field overhead (sometimes unacceptable).