Proposal-temporal: Should Temporal.MonthDay#toDate have a disambiguation option like Temporal.MonthDay#with?

[timrwood]

The disambiguation option for Temporal.MonthDay#with is nice for handling days out of the month range without catching errors. Could a similar option be added to Temporal.MonthDay#toDate so that leap days can handle days out of the month range without catching errors?

const leapDay = new Temporal.MonthDay(2, 29)
leapDay.with({ day: 30 }).toString() // "02-29"
leapDay.with({ day: 30 }, { disambiguation: 'constrain' }).toString() // "02-29"
leapDay.with({ day: 30 }, { disambiguation: 'reject' }).toString() // Uncaught RangeError
// converting to a date in a non-leap year always throws a RangeError
leapDay.toDate(2019) // Uncaught RangeError

Adding an optional disambiguation option to toDate could use the same defaults as with. Here is the proposed behavior:

const leapDay = new Temporal.MonthDay(2, 29)
leapDay.toDate(2019).toString() // "2019-02-28"
leapDay.toDate(2019, { disambiguation: 'constrain' }).toString() // "2019-02-28"
leapDay.toDate(2019, { disambiguation: 'reject' }).toString() // Uncaught RangeError

The use case for this is illustrated in the birthday cookbook example: https://tc39.es/proposal-temporal/docs/cookbook.html#birthday-in-2030

If the birthday was provided with user input, 2-29 is a valid birthday, but birthday.toDate(2019) would raise an error, so the code would have to be wrapped in a try/catch or explicitly handle 2-29 some other way.

[timrwood]

Unrelated, this proposal is a really nice set of primitives, and I really like the thought put into the conversions between them, nice work!

[ptomato]

Thanks very much! I originally was going to put this on the feedback list but the more I think about it, the more I think the lack of this option is a bug, or at least a straightforward inconsistency with the other methods.