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.

Sign up for GitHub

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

Jump to bottom

Explicitly include annotated types in the various type categories. #747

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Explicitly include annotated types in the various type categories. #747

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ae8b5bd
Explicitly include annotated types in the various type categories.
Ms2ger Jun 27, 2019
4bb39f3
Also include nullable types in the various type categories.
Ms2ger Jun 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
48 changes: 32 additions & 16 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5313,22 +5313,32 @@ The following types are known as <dfn id="dfn-integer-type" export>integer types
{{unsigned short}},
{{long}},
{{unsigned long}},
{{long long}} and
{{unsigned long long}}.
{{long long}},
{{unsigned long long}},
any [=nullable types=] whose [=nullable types/inner type=] is an [=integer type=],
and any [=annotated types=] whose [=annotated types/inner type=] is an [=integer type=].

The following types are known as <dfn id="dfn-numeric-type" export>numeric types</dfn>:
the [=integer types=],
{{float}},
{{unrestricted float}},
{{double}} and
{{unrestricted double}}.
{{double}},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... With this change there are a few things that are a bit odd:

  1. https://heycam.github.io/webidl/#es-overloads step 12.12 no longer needs to worry about "a nullable numeric type" or "an annotated type whose inner type is one of the above types", since those will be included under "numeric type", no? Same thing for step 12.14. And 12.13 given the "string type" changes below.

  2. There are various other places in the spec that mention "numeric types" but they all already handle unwrapping nullable and annotated types. Maybe this is OK; it's just a little confusing to consider the table in the distinguishability section, for example, when "numeric types" could in theory include long? but in practice can't because we unwrapped that already...

{{unrestricted double}},
any [=nullable types=] whose [=nullable types/inner type=] is a [=numeric type=],
and any [=annotated types=] whose [=annotated types/inner type=] is a [=numeric type=].

The <dfn id="dfn-primitive-type" export>primitive types</dfn> are
{{boolean}} and the [=numeric types=].
{{boolean}},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, this leads to the slightly odd situation that the PrimitiveType production no longer matches the set of "primitive types". Further, the prose around ConstType says:

The type of a constant (matching ConstType) must not be any type other than a primitive type.

with that last it linking to this definition but it would now actually means a stronger restriction than what that link provides.

the [=numeric types=],
any [=nullable types=] whose [=nullable types/inner type=] is a [=primitive type=],
and any [=annotated types=] whose [=annotated types/inner type=] is a [=primitive type=].

The <dfn id="dfn-string-type" export>string types</dfn> are
{{DOMString}}, all [=enumeration types=],
{{ByteString}} and {{USVString}}.
{{ByteString}},
{{USVString}},
any [=nullable types=] whose [=nullable types/inner type=] is a [=string type=],
and any [=annotated types=] whose [=annotated types/inner type=] is a [=string type=].

The <dfn id="dfn-typed-array-type" export>typed array types</dfn> are
{{Int8Array}},
Expand All @@ -5338,18 +5348,24 @@ The <dfn id="dfn-typed-array-type" export>typed array types</dfn> are
{{Uint16Array}},
{{Uint32Array}},
{{Uint8ClampedArray}},
{{Float32Array}} and
{{Float64Array}}.
{{Float32Array}},
{{Float64Array}},
any [=nullable types=] whose [=nullable types/inner type=] is a [=typed array type=],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But here we couldn't simplify overload resolution step 12.7 because for the annotated/nullable types the name would not match...

and any [=annotated types=] whose [=annotated types/inner type=] is a [=typed array type=].

The <dfn id="dfn-buffer-source-type" export>buffer source types</dfn>
are {{ArrayBuffer}},
The <dfn id="dfn-buffer-source-type" export>buffer source types</dfn> are
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this part changed, the claim that "buffer source types are simply references to objects" stops being true, no?

And "Values of the IDL buffer source types are represented by objects of the corresponding ECMAScript class" also stops beign true.

{{ArrayBuffer}},
{{DataView}},
and the [=typed array types=].

The {{object}} type,
all [=interface types=], and
all [=callback interface types=]
are known as <dfn id="dfn-object-type" export>object types</dfn>.
the [=typed array types=],
any [=nullable types=] whose [=nullable types/inner type=] is a [=buffer source type=],
and any [=annotated types=] whose [=annotated types/inner type=] is a [=buffer source type=].

The <dfn id="dfn-object-type" export>object types</dfn> are
the {{object}} type,
all [=interface types=],
all [=callback interface types=],
any [=nullable types=] whose [=nullable types/inner type=] is an [=object type=],
and any [=annotated types=] whose [=annotated types/inner type=] is an [=object type=].

Every type has a <dfn id="dfn-type-name" export>type name</dfn>, which
is a string, not necessarily unique, that identifies the type.
Expand Down