Re: [whatwg/webidl] Editorial: Define the WebIDL string types in terms of Infra types. (PR #1287)

@annevk commented on this pull request.

I mainly found problems with the existing text. Thanks for tackling this!

> @@ -2097,15 +2099,15 @@ the value is the IDL {{undefined}} value.
              :  {{DOMString}}
              :  an [=enumeration=] type
              :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token
-                is the sequence of 16 bit unsigned integer code units
-                (hereafter referred to just as <dfn id="dfn-code-unit">code units</dfn>)
+                is the sequence of 16 bit unsigned integer [=code units=]
                 corresponding to the UTF-16 encoding of |S|.

I think we can just say that the value is |S|. We already know the value is a scalar value string from how we collect it. And those are compatible with strings.

> @@ -2097,15 +2099,15 @@ the value is the IDL {{undefined}} value.
              :  {{DOMString}}
              :  an [=enumeration=] type
              :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token
-                is the sequence of 16 bit unsigned integer code units
-                (hereafter referred to just as <dfn id="dfn-code-unit">code units</dfn>)
+                is the sequence of 16 bit unsigned integer [=code units=]
                 corresponding to the UTF-16 encoding of |S|.
              :  {{ByteString}}
              :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token
                 is the sequence of 8 bit unsigned integer code units
                 corresponding to the UTF-8 encoding of |S|.

If we want to continue to treat these as byte sequences (I could see an argument for isomorphic string, though that would be a bigger change with downstream impact on Fetch and such), we should use assert that |S| doesn't contain any code points higher than U+00FF and use isomorphic encode. UTF-8 is plain wrong.

>                  corresponding to the UTF-16 encoding of |S|.
              :  {{ByteString}}
              :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token
                 is the sequence of 8 bit unsigned integer code units
                 corresponding to the UTF-8 encoding of |S|.
              :  {{USVString}}
-             :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token is |S|.
+             :: The value of the <emu-t class="regex"><a href="#prod-string">string</a></emu-t> token
+                is the [=scalar value string=] whose [=code points=] are |S|.

I think the original text was already accurate here.

> @@ -5791,9 +5794,9 @@ The {{bigint}} type is an arbitrary integer type, unrestricted in range.
 
 <h4 oldids="dom-DOMString" id="idl-DOMString" interface>DOMString</h4>
 
-The {{DOMString}} type corresponds to
-the set of all possible sequences of [=code units=].
-Such sequences are commonly interpreted as UTF-16 encoded strings [[!RFC2781]]
+The {{DOMString}} type corresponds to [=strings=].
+The sequence of unsigned 16-bit integers in a [=string=]
+is commonly interpreted as a UTF-16 encoded string [[!RFC2781]]
 although this is not required.

I think we should drop the bit about UTF-16 while here.

> @@ -7471,12 +7474,11 @@ value when its bit pattern is interpreted as an unsigned 64 bit integer.
 
 <div id="USVString-to-es" algorithm="convert an USVString to an ECMAScript value">
 
-    An IDL {{USVString}} value is [=converted to an ECMAScript value|converted=]
-    to an ECMAScript value by running the following algorithm:
-
-    1.  Let |scalarValues| be the sequence of [=scalar values=] the {{USVString}} represents.
-    1.  Let |string| be the sequence of [=code units=] that results from encoding |scalarValues| in UTF-16.
-    1.  Return the String value that represents the same sequence of [=code units=] as |string|.
+    The result of [=converted to an ECMAScript value|converting=]
+    an IDL {{USVString}} value to an ECMAScript
+    value is the String
+    value that represents the sequence of [=code units=]
+    in the IDL {{USVString}}.

Do we have to define this at all given how Infra defines them to be compatible?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1287#pullrequestreview-1393653401
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1287/review/1393653401@github.com>