Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determination of the type of an object with uninitialized fields #3482

Open
d01c2 opened this issue Nov 19, 2024 · 2 comments
Open

Determination of the type of an object with uninitialized fields #3482

d01c2 opened this issue Nov 19, 2024 · 2 comments

Comments

@d01c2
Copy link
Contributor

d01c2 commented Nov 19, 2024

I have a question about how to determine the type of an object with uninitialized fields, as a continuation of the discussion in PR #3383.

Let’s assume the execution process of the program below:

new Promise(function () {});

This program follows the step of 27.2.3.1 Promise ( executor ) during execution. In step 8, it calls 27.2.1.3 CreateResolvingFunctions( promise ) with an argument _promise_, whose [[PromiseResult]] field is uninitialized. In this example, the annotated parameter type of the callee is a Promise, and 27.2.6 Properties of Promise Instances says the [[PromiseResult]] field of a promise instance should hold an ECMAScript language value.

I'm unsure if we can interpret the actual argument above as a Promise.

Similarly, the same JavaScript program also follows the steps of 27.5.3.8 CreateIteratorFromClosure ( closure, generatorBrand, generatorPrototype [ , extraSlots ] ). It calls27.5.3.1 GeneratorStart ( generator, generatorBody ) in step 14. The passed argument _generator_ has an uninitialized [[GeneratorContext]] field, which should be initialized in this case.

Additionally, I'm aware of the following statement:

Unless specified otherwise, the initial value of an internal slot is the value undefined.

which is specified in 6.1.7.2 Object Internal Methods and Internal Slots. Does this statement mean that the value of uninitialized field should be considered as undefined in case of type determination of an object?

@michaelficarra
Copy link
Member

I'm unsure if we can interpret the actual argument above as a Promise.

I agree that this is unclear. We're going to try to clear up the initialisation of internal slots for objects created this way as part of #3399.

I'll leave this open as a reminder for us to update our description of the various types of objects that are created in this way to define them in terms of their essential internal slots. I think those two changes together should resolve your concerns.

@michaelficarra michaelficarra added the editor call to be discussed in the next editor call label Nov 19, 2024
@bakkot
Copy link
Contributor

bakkot commented Nov 20, 2024

#3491 handles the Promise part of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants