Consider removing fallback paths in CalendarFields and CalendarMergeFields

[anba]

CalendarFields and CalendarMergeFields both have fallback paths when "fields" resp. "mergeFields" isn't present. This approach isn't used anywhere else in the Temporal spec, for example all other Calendar API methods are required and will throw an error when they aren't present on an Calendar-like object.

I'm not sure if this is just a left-over from the initial design, which had more fallback paths. For example certain Temporal.TimeZone.prototype methods didn't contain brand checks and were applicable for any object. One example:

• GetTemporalDateTimeFor default to Temporal.TimeZone.prototype.getPlainDateTimeFor when the getPlainDateTimeFor property wasn't present. And Temporal.TimeZone.prototype.getPlainDateTimeFor was applicable for any object.

The minimal implementation for both methods is relatively simple, so it shouldn't be too much to ask that users provide their own implementation.

• fields just needs to return its input.
• mergeFields combines both objects and has to perform some special-casing for "month" and "monthCode".

It's also worth noting that user-defined calendars which use fields like "era" and "eraYear" have to define their own version of mergeFields anyway.

Minimal implementation example:

class MyCalendar {
  // Other methods omitted.

  fields(fieldNames) {
    return fieldNames;
  }

  mergeFields(fields, additionalFields) {
    if ("month" in additionalFields || "monthCode" in additionalFields) {
      let {month, monthCode, ...rest} = fields;
      return {...rest, ...additionalFields};
    }
    return {...fields, ...additionalFields};
  }
}

[ptomato]

I believe we did keep these intentionally even though the rest of the fallbacks were not present, because many userland calendars wouldn't have to have these. I don't feel strongly either way though.

[ptomato]

cc @sffc

[ptomato]

In the champions meeting of 2023-01-05 we decided to accept @anba's recommendation to remove these in order to reduce complexity in the proposal.

[ljharb]

@ptomato i'm not seeing anything in here that explains the benefits of removing the fallbacks. All I've seen is points about how it might not be that harmful to remove them.

[ljharb]

@ptomato i understand this has consensus, but nobody yet has explained why this is a good thing.

[ptomato]

Sorry, I assumed this had been answered by the slide I presented. Here's a slightly more elaborate, non-slide-deck-based explanation:

There were two reasons to have these fallbacks:

1. Guard against deleting properties off the prototype: delete Temporal.Calendar.prototype.fields and delete Temporal.Calendar.prototype.mergeFields.
2. Convenience when implementing the Calendar protocol with a plain object (that doesn't extend Temporal.Calendar)

With the optimization from #1808 adopted, built-in calendars no longer observably look up methods. Guarding against deleted prototype properties is no longer necessary in most cases, because built-in calendars will continue to work the same if those properties are deleted.

Also with #1808, we now require objects implementing the Calendar protocol to implement all of the methods anyway, so that we can unambiguously say whether an object implements the protocol or not — the way we distinguished this previously was a confusing, weird corner of the proposal, which is now able to be eliminated altogether. So omitting fields and mergeFields implementations for convenience on plain objects is no longer a thing, because they must be present in order for the object to be considered to implement the protocol.

With those two reasons no longer applying, we didn't see any reason to push back against the request for less complexity. So as a literal answer to your question, I guess "less complexity, because it turned out not to be needed" is the good thing.

[ljharb]

Gotcha, thanks for typing it out.