Proposal-temporal: Spec text should explain status as a built-in module

[littledan]

This proposal is to create a built-in temporal module, according to the README. Right now, the spec text focuses on the library itself, but doesn't explain how temporal is a built-in module. We should make the spec text a bit more precise this way.

The only specification I know of that defines a built-in module is async-local-storage; I'm not sure if we want to use the conventions in that spec text or something different. We might want to use IDL.

[ljharb]

Instead I’d suggest altering that part of the readme; built-in modules don’t exist yet, and there’s not even consensus that “only using a builtin module instead of a global” is desirable or possible.

[domenic]

The conventions in ALS will likely be changing, so happy for others to forge a path here.

[littledan]

@ljharb The champions have been pretty clear about their intentions here of using a built-in module, and this was part of the proposal as it was approved for Stage 2. As we work towards Stage 3, we can figure out these details and work towards stronger consensus that we actually do want to have it as a built-in module.

[zenparsing]

Let's proceed on the assumption that they are both desirable and possible and see what happens!

[ljharb]

That will mean this stage 2 proposal can’t reach stage 3 until the much more contentious and nebulous stage 1 built in modules proposal reaches stage 4. I’ve always heard the champions’ opinion in meetings as “globals or builtin, as long as it goes in” - I’d like to hear their response on this thread.

[zenparsing]

I don't think we need to ask anyone to die on any hamburger hills. It's all good.

[mj1856]

I’ve always heard the champions’ opinion in meetings as “globals or builtin, as long as it goes in” - I’d like to hear their response on this thread.

Speaking for myself, I concur. I would prefer a built in module, but globals would suffice if that's not possible The API surface doesn't change at all either way, as far as I can foresee.

[littledan]

To clarify, I don't want to block anything on anything; I am looking into how we should do the infrastructure for built-in modules, and put this as a placeholder for my work.

[littledan]

In our recent Temporal meeting, we decided to give it a go and try to present this as a built-in module. Our thought is, it won't be the end of the world if this proposal lives as a polyfill for a little bit, while built-in module infrastructure is being worked out. We can fall back to it being a global namespace or something if built-in modules later doesn't seem to be happening by the time we want to go for Stage 3.

Whether it's a built-in module affects a couple aspects of this proposal:

• The "Civil" prefix (see #33; being in a module means we have the option of not having a prefix, though we may still want one)
• Where we put the polyfill. We plan to use @std/temporal to put our polyfill for now (thanks @jdalton!). (I hope using a major version number 0 before this is standard should avoid issues of people depending on unstable early versions.)
• Let's draft spec text which would explain how this proposal fits in with built-in module infrastructure. I think this will be a useful case study to help the built-in module infrastructure proposal move forward.

[ljharb]

I strongly object to that, and would have blocked stage 2 had that been the plan of record.

I do not think it appropriate for something prior to stage 2 (builtin modules) - where there is not yet consensus it wil even ever be part of the language - to be even implied as a blocker for something stage 2 and above (like Temporal).

[littledan]

We're not proposing this for stage advancement right now, we're just working on it as a champion group. We'll have to work this out thoroughly before proposing it for Stage 3. If built-in modules aren't ready when we want to advance Temporal to Stage 3, we'll have to reconsider the connection.

[ljharb]

What I mean is, "it's a built in module" is not part of the consensus for this proposal being stage 2. I think that this change should require a new consensus, and perhaps go back to stage 1, if it's not going to provide a global name by which it can be accessed (i consider this a stage 2 requirement, not a stage 3 requirement).

[littledan]

I don't understand the issue. I think whether something is a built-in module should be figured out by Stage 3, and that this proposal meets Stage 2 requirements with the module-ness of it being an open question to continue to refine. This is consistent with the last time we discussed the module-ness of Temporal in TC39.

SYG: The API surface: Do we have anything that introduces a new global? vs potentially a module?

DD: We had a big discussion about module/namespace/global

MJN: As with other proposals, this decision will be deferred, depending on where the committee sits at the time with built-in modules

I don't see why the champion group shouldn't look down the module path here, and maintain a draft which integrates with that. We're not yet asking for committee buy-in on the definitive answer as "yes, it will be in a module", just like we didn't ask the committee for buy-in on the definitive answer of "no, it will not be in a module" when proposing for Stage 2 (surely that would've led to concerns being raised).

[littledan]

In particular, the comment I posted seems consistent with your earlier comment https://github.com/tc39/proposal-temporal/issues/98#issuecomment-428677721 -- we can't reach Stage 3 until we work through all of this. I agree with that judgement.

[ljharb]

“globals or builtin, as long as it goes in”

That's indeed what I find appropriate for stage 2, as well as that plus "a preference for a built-in module if the option is available". "built-in module, unless we're forced not to" imo is not.

In other words, the stage 2 requirement "all major semantics, syntax and API are covered" imo requires designating how the feature would be accessed - which includes, for things that can't be derived from syntax, a global name.

Since at the moment there is no such thing as a built-in module, I find it very inappropriate for a proposal with stage 2 - a commitment to adding it to the language - to be declaring that the only way to access the proposal's features is through a nonexistent mechanism.

[littledan]

Are you demanding that the proposal be demoted a stage unless we stop discussing module integration? We all agree that, if it ultimately doesn't work out with built-in modules, we would make this a global.

[ljharb]

we decided to give it a go and try to present this as a built-in module.

We all agree that, if it ultimately doesn't work out with built-in modules, we would make this a global.

To me, these statements don't really agree with each other. Built-in modules don't yet exist; presenting a proposal as one isn't something that makes sense to me. What I would expect from https://github.com/tc39/proposal-temporal#overview--motivation is to explicitly list the name(s) it's intended to be under as a global. If you'd also like it to say something about preferring a built-in module once such an option exists, that seems fine with me, but stage 2 means we've committed to something being in the language, and at the moment, that effectively means it needs to be accessible either by syntax or by globals.

[wycats]

@ljharb it seems unfortunate for every proposal champion to have to do the thorny work of finding new suitable globals for their API simply because we haven't been able to convince ourselves to ship builtins modules and design a structure for them.

What is the strong rationale for rejecting builtin modules forever at this point?

[littledan]

@ljharb I can understand if you don't think this should be presented as a built-in module, but I don't see the contradiction between those statements. I think Stage 2 means that we've agreed we want to eventually get it in the language, and we have some more details to work out, though there's a good high-level outline. I think the five types and operations on them, together with their definitions, meet those requirements.

It seems like you're coming from an idea that there should be committee consensus to be able to maintain documentation for this proposal in the context of another proposal. On the other hand, you could argue that we would need committee consensus in order to tell the champion group to restrict the scope of their investigation. Not thinking about now Temporal would relate to built-in modules seems to go in contrast to the committee's interest in addressing cross-cutting concerns.

I think we just have multiple points of view in the committee on all of these matters; there's no absolute right answer or obvious default position that we would need consensus to go the other way on.

Let's just try to positively encourage good technical development, and do our best to help out with evaluation, but not shut off paths prematurely.

[ljharb]

@wycats I'm not rejecting them forever (that'd be a different discussion, where I'm happy to explain why I'm skeptical that it can ever move to stage 2), I'm saying that it's not appropriate for stage N proposals to depend on a stage < N proposal to be able to access them at all.

@littledan I'm saying that stage 2 means major semantics, etc are set. "It's a global" is a major semantic. Changing that without committee consensus isn't appropriate.

Specifically, I think it is shutting off a path prematurely to present a proposal as only a built-in module - because "as a global" is a path. I'd like this proposal to continue to present both (viable) paths, to handle both the event where built-in modules progresses, and the event where it does not.

[littledan]

I don't think committee review is needed for all development steps on a proposal. This request is not reasonable.

I am not sure if it's productive to keep discussing here. The lack of further response from me doesn't mean I am convinced.

[ajklein]

@ljharb I think you're misinterpreting stage 2. From the process doc, under "acceptance signifies" for stage 2:

The committee expects the feature to be developed and eventually included in the standard

Here, I take "the feature" to be "an expanded date/time library". While the process doc says that at Stage 2 it's expected that major syntax and semantics are covered, they are not _set_ at this time. Stage 3 is where those are meant to be solidified.

[ljharb]

Perhaps; let's get clarity on that during the meeting. To me, "an actual way to access the feature" is a requirement for stage 2, and that includes specifying how non-syntax-derived features will be globally accessible.

[littledan]

OK, Temporal isn't on the agenda this meeting, but feel free to add something. Note that I will be calling in from remote.

[ljharb]

As will I; I'll add an item.

[littledan]

I don't think we had an agenda item to discuss this question, but in the March 2019 TC39 meeting, there was a Temporal update explaining the status as a built-in module. At this point, I think it'd be appropriate to start writing spec text towards making this concrete, even as we have more to work through to get Stage 3 consensus on the proposal.

[ljharb]

Had i been in the room i would have added a queue item about it (that hour overlapped with the node modules meeting) - but nothing imo should not be able to achieve stage 2, even, let alone 3, as a built in module until that proposal is at least at that stage, if not higher.

[littledan]

Well, we'll probably discuss Temporal at another TC39 meeting not so far out. Maybe that would be a good time to discuss this idea, if you didn't give a chance to give your thoughts at the last meeting. In the future, it'd be good to note your schedule constraints on the agenda, or add an agenda item to discuss this particular issue.

[ljharb]

I did note them with the chairs for the last meeting, but the conflict became unavoidable. Regardless, an “update” generally doesn’t result in a change of consensus.