Constructors should not accept invalid input

[gibson042]

I find it surprising (in a negative sense) that Date, Time, DateTime, YearMonth, MonthDay, and Duration constructors have disambiguation parameters, allowing for e.g. new Temporal.YearMonth(2019, 13) to succeed while Temporal.YearMonth.from("2019-13") rightfully fails. This also seems to have spread to the with<Type> methods (withTime, withDate, withYear, and withDay), which I thought were intended to losslessly preserve all data from the receiver and therefore have no use for disambiguation.

[littledan]

cc @ryzokuken , resident disambiguation expert. (Not knowing this area in detail, I might be OK with this being a bit stricter.)

[ryzokuken]

@gibson042 the constructors handle invalid input through disambiguation params while the from helpers fail because the constructors are supposed to be lower level constructs that accept a wider range of inputs while ideally, the users would almost always stick with from. It's not much different the Node.js Buffer class where ideally you would always use from or alloc and never really the actual Buffer constructor.

[gibson042]

That seems to throw away many benefits that Temporal should have, some of which I believe have been cited as explicit improvements over Date. Why is new Temporal.Date(2019, 13, -9001) acceptable while new Date(2019, 13, -9001) is considered bad, and why should we permit Temporal.Date.from("2019-11-18").withTime({hour: 0, minute: 1e7}) to succeed under any circumstances?

[ptomato]

Meeting Jan. 27: Constructors should be strict, and we need to find another layer of the API to put the disambiguation.

[ptomato]

Moving the disambiguation from the constructor into from() raises one question that I hadn't anticipated:

Temporal.Date.from({ year: 2019, month: 1, day: 32 }, { disambiguation: 'constrain' })  // => 2019-01-31
Temporal.Date.from('2019-01-32', { disambiguation: 'constrain' })  // throws

Since this is an invalid ISO 8601 string to begin with, this should throw. This seems confusing to API users who would expect that the constrain means they'll get a valid date back. But on the other hand, it doesn't seem right to disallow or ignore disambiguation when parsing a string, because this seems like it should be allowed, as in #388:

Temporal.Duration.from('PT100M', { disambiguation: 'balance' })  // => PT1H40M

The difference is that PT100M is a valid ISO 8601 string, but it does seem a bit confusing to an API user at first glance.

[gibson042]

This doesn't look terrible to me; it's just a reflection of the differences between strings (required to be valid per ISO 8601) and objects (inherently more flexible and in need of extra massaging).

[ptomato]

Fair enough. I pushed an extra commit to this branch making a note of this in the documentation, to clear up any potential confusion.