Lack of throwing for most Object as Calendar in new Temporal.Plain*()?

[FrankYFTang]

This is really a question which I am puzzle, not a suggestion or opinion. I just try to understand the logic behind this.

So... if I pass in a object, except those which have a calendar property but anything else , something like {foo: "bar", year:5} as calendarLike to the new Temporal.Plain*() constructor call, is it by design NOT to check that and throw any error?

For example, let's say we have the following code:

let d1 = new Temporal.PlainDate(2021, 3, 15, {foo: 'bar'});

it won't throw at this moment, right? Is thsi by design?

3.1.1 Temporal.PlainDate ( isoYear, isoMonth, isoDay [ , calendarLike ] )
https://tc39.es/proposal-temporal/#sec-temporal-plaindate-objects

8. Let calendar be ? ToTemporalCalendarWithISODefault(calendarLike).
   ToTemporalCalendarWithISODefault( {foo: 'bar'} )

12.1.22 ToTemporalCalendarWithISODefault ( temporalCalendarLike )
https://tc39.es/proposal-temporal/#sec-temporal-totemporalcalendarwithisodefault
2. Return ? ToTemporalCalendar(temporalCalendarLike).

12.1.21 ToTemporalCalendar ( temporalCalendarLike )
https://tc39.es/proposal-temporal/#sec-temporal-totemporalcalendar

1. If Type(temporalCalendarLike) is Object, then
   b. If ? HasProperty(temporalCalendarLike, "calendar") is false, return temporalCalendarLike.

so ToTemporalCalendar({foo: 'bar'} ) return {foo: 'bar'}
and ToTemporalCalendarWithISODefault ({foo: 'bar'}) return {foo: 'bar'}
and after running
8. Let calendar be ? ToTemporalCalendarWithISODefault(calendarLike).
in 3.1.1 Temporal.PlainDate ( isoYear, isoMonth, isoDay [ , calendarLike ] )
calendar is {foo: 'bar'}
and then call 9.
9. Return ? CreateTemporalDate(y, m, d, calendar, NewTarget).
which is now
9. Return ? CreateTemporalDate(2021, 3, 15, {foo: 'bar'}. NewTarget).
https://tc39.es/proposal-temporal/#sec-temporal-createtemporaldate
and
12. Set object.[[Calendar]] to calendar.
13. Return object.

so the Temporal.PlainDate has a [[Calendar]] point to {foo: 'bar'}

and no exception will be throw at this point. IS this what the champion intend it to be?

and later

let y = d1.year

3.3.4 get Temporal.PlainDate.prototype.year
will call
4. Return ? CalendarYear(calendar, temporalDate).

and

2. Let result be ? Invoke(calendar, "year", « dateLike »).

and at this point a TypeError got throw

d1.year
     ^
TypeError: year is not a function

Is this how it supposed to work?

let d1 = new Temporal.PlainDate(2021, 3, 15, {foo: 'bar'}); // successfully create the PlainDate
let d2 = new Temporal.PlainDate(2021, 3, 15); // successfully create the PlainDate
let y1 = d1.year; // throw TypeError
TypeError: year is not a function
    at PlainDate.get year [as year] (<anonymous>)
let y2 = d2.year; // 2021

@sffc @justingrant @ptomato @Ms2ger @ryzokuken @ljharb @littledan
or is this a mistake in the spec and we supose to throw error while the constructor was called with {foo: 'bar'}

This is purely a question, no opinion. I am just not sure my implementation is correct.

[ptomato]

For the original context, see #300. Another related discussion is #1294. I agree this is not like the way datetime-like objects work, but if we want to support plain-object calendars as implementations of the calendar protocol, there isn't really a "shape" to which a calendar-like object must conform, since calendar methods are optional. So I believe the way you described it is correct.

As per #1432, if this is causing problems in the implementation, especially with respect to optimizability, I think we should put it on the agenda to discuss in a Temporal champions meeting.

[FrankYFTang]

causing problems
NO, this is not the case. I am just not sure of the intent of the design and want to double check with you folks for this particular issue.

there isn't really a "shape" to which a calendar-like object must conform, since calendar methods are optional.

Really!?! So... there are no minimum requirement for the calendar object and could be Object?

Again, I don't feel there is a need for discussion of this in the agenda. I just need to confirm that is the design intend for this issue. I am closing down this issue since ptomato already answer my question.

[ptomato]

OK, I'm happy to put it on next week's agenda if you change your mind and want to discuss it (or @sffc since I saw you thumbsed-up the comment) but unless I hear anything to the contrary I'll leave this as closed.