Should from() always return new objects?

[Ms2ger]

In #231 (comment), @ljharb says:

even if immutable and frozen, it still has identity (===, Object.is, Map/WeakMap keys, Set/WeakSet membership) and it's important to be able to easily create a new identity.

It seems like Temporal.Date.from(temporalDate) would be the most sensible way to support this requirement, more so than anything involving with().

I seem to recall that we discussed this before, but I can't find the discussion now.

[sffc]

from() should delegate to, e.g., the dateFromFields() method on the calendar. So, if we add a requirement that from() always returns a new object, we need to decide to either (1) make that a recommendation for Calendar implementers, or (2) enforce it by cloning the object in the from() spec.

[ptomato]

I support this change even more after discovering that you otherwise cannot balance an existing Duration by calling Temporal.Duration.from(existingDuration, { disambiguation: 'balance' }).

[ptomato]

I didn't notice before, but this is a duplicate of #232.

[gibson042]

#232 appears to have been resolved without an explicit decision on this point; I'm going to reopen it to avoid further duplication until that happens.

[ptomato]

I'm fairly sure we have decided in some other context that from() always returns a new object (except for TimeZone and Calendar where it cannot), just not in the context of #232.

[gibson042]

I thought so too, but that's not the currently the case in the slides or (part of) the spec.

[ptomato]

I think the language in the slides is ambiguous and could be changed, but the spec text is correct as far as I can tell; ToTemporalFoo returns the same instance when used internally for coercion, but Temporal.Foo.from contains an extra step that clones the object if it is already of the correct type.

[ptomato]

I double-checked this, and there was indeed a discrepancy in the ZonedDateTime.from spec text. I've opened a pull request to address it.