00:18:49  * gsneddersjoined
00:28:17  * gibson042quit (Read error: Connection reset by peer)
00:33:59  * gibson042joined
00:41:17  * gibson042quit (Ping timeout: 255 seconds)
00:49:30  * marxoquit (Ping timeout: 260 seconds)
02:44:35  * gibson042joined
02:56:39  * Fishrock123quit (Remote host closed the connection)
02:57:17  * Fishrock123joined
03:03:50  * Fishrock123quit (Remote host closed the connection)
03:04:51  * Fishrock123joined
03:25:51  * zbranieckiquit (Ping timeout: 240 seconds)
03:32:28  * zbranieckijoined
03:45:05  * shachafjoined
03:56:37  * howdoijoined
04:20:26  * gibson042quit (Ping timeout: 255 seconds)
04:54:21  * soareschenjoined
05:09:28  * jmdyckquit (Remote host closed the connection)
06:03:52  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:08:01  * jridgewellquit (Quit: Connection closed for inactivity)
06:44:25  * Chris_joined
07:10:24  * brabjoined
08:06:20  * howdoiquit (Quit: Connection closed for inactivity)
08:18:40  * Fishrock123quit (Remote host closed the connection)
08:19:17  * Fishrock123joined
08:34:26  * Fishrock123quit (Remote host closed the connection)
08:34:51  * Fishrock123joined
08:37:55  * Fishrock123quit (Client Quit)
09:23:00  * Chris_quit (Ping timeout: 260 seconds)
09:25:36  * AtumTjoined
09:26:45  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:53:04  * caridyquit (Ping timeout: 248 seconds)
10:29:32  <annevk>Are there plans or have there been plans shutdown to offer fast mapping between Uint16Array and String?
10:30:35  <annevk>Would String.fromCharCode() be the recommended way and hope that implementations optimize?
10:50:59  <annevk>littledan: FWIW, my one concern with referencing UTS documents is that they generally seem poorly tested/implemented; I've found out in practice at least for text wrapping and IDNA that this was the case
10:51:48  <annevk>littledan: and they're also generally written in a less algorithmic style leading to ambiguities and less clarity than the stuff that depends on them
10:51:54  <annevk>littledan: prolly related
10:52:22  <annevk>littledan: so I'd advice that if you take on such a dependency you also take on testing the dependency
11:07:39  <annevk>littledan: also IDL and ECMAScript <3
11:08:04  <annevk>littledan: taken a long time for that idea to get some traction, but I guess the bigger standard library is helping
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:42  * mylesborinsjoined
11:26:10  * marxojoined
11:54:05  * H|f|ishjoined
12:02:30  * jowejoined
14:01:10  * marxo_joined
14:01:11  * marxoquit (Read error: Connection reset by peer)
14:02:02  * jmdyckjoined
14:39:37  * caridyjoined
14:43:41  * caridyquit (Ping timeout: 240 seconds)
15:04:14  * nmostafajoined
15:24:33  <littledan>annevk: I haven't heard of a proposal like this for String/Uint16Array correspondence. Based on the way strings are implemented in V8, I'd expect that implementations would need to copy, at least sometimes.
15:26:04  <annevk>Domenic suggested in #whatwg that String <> Uint16Array conversion, mostly to make Map() work better, is really a hack due to Map not exposing its equality protocol, so not worth adding conversion features for
15:26:13  <littledan>The V8 team has tossed around the idea of proposing a standard library function for String.fromCharCode.apply (which at some point had performance limitations in V8, though certain other engines handled OK); my suggestion was to look into getting String.fromCharCode.apply optimized reliably across engines, and standardize a new function if that doesn't work
15:26:19  <littledan>I'm not sure which conversion you're talking about
15:26:44  <annevk>littledan: sorry, mapping, not conversion
15:26:57  <Domenic>https://freenode.logbot.info/whatwg/20171205#c1375107 onward
15:26:58  <littledan>for IDL and ECMAScript, I'm a little worried about getting hung up on surface syntax issues (I can imagine us dividing into "Must be IDL" and "Must not be IDL" camps); we'll see what happens
15:27:33  * caridyjoined
15:27:48  <annevk>littledan: FWIW, I think IDL syntax can change if that is the blocker
15:28:09  <annevk>littledan: we are already getting experience with changing some syntax across dozens and dozens of documents
15:28:10  * caridyquit (Remote host closed the connection)
15:28:27  <annevk>littledan: we should just do it if it makes things better and as long as we continue to believe the future is bigger than the past
15:28:55  <annevk>littledan: it'd be really sad to die on that hill
15:29:35  <littledan>my strawman IDL change would be s/interface/class/ and use @attribute(arg) @attribute2(arg2) for extended attributes rather than [attribute=arg,attribute2(arg2)]
15:29:37  <littledan>totally superficial
15:30:06  <annevk>class especially seems like a good one
15:30:20  <annevk>And one that's already logged somewhere is something we should do at some point
15:30:23  <littledan>on top of that, maybe make some aliases for things that appear in ECMAScript and don't really benefit from another name, like Number for double, and String for DOMString
15:31:02  <annevk>Yeah, at some point we were going to rename DOMString to String, but some silly reason blocked it that would not fly today
15:31:19  <littledan>also, I guess this is the easy part, but we'd have to make a convenient syntax for non-enumerable methods and namespacing that doesn't have "Legacy" in the name, and also syntax for own instance properties
15:31:32  <annevk>I think we can do most of those and maybe even should just do, even if ECMAScript doesn't buy in
15:31:49  <littledan>tobie: ^
15:31:53  <annevk>it'll be better for web developers
15:32:26  <littledan>why is it that most of my projects end up making me want to change WebIDL? I don't think this is the typical experience for standards authors...
15:32:51  <littledan>anyway, making WebIDL more JavaScript-y and then just using that seems like the best of all worlds
15:33:47  <annevk>infrastructure is fun
15:34:03  * caridyjoined
15:34:10  * caridyquit (Remote host closed the connection)
15:35:08  <tobie>As annevk mentioned above, we're getting there in terms of being able to do large syntax changes and get it adopted by specs.
15:35:34  <littledan>what do you think about these drastic syntax changes?
15:36:00  * caridyjoined
15:36:28  <littledan>there's no conflict with existing syntax; it could be introduced as a variant and kept that way for a while during a transition
15:37:21  <tobie>I agree with you, see: https://github.com/heycam/webidl/issues/477. But that's not a consensual position at all.
15:37:22  <Domenic>I'm not sure about attribute/class since at least for web classes they don't match JS classes
15:37:43  <Domenic>number <-> unrestricted double, not double, FWIW.
15:38:06  <littledan>there's also a layering thing: Although WebIDL is pretty well self-contained and doesn't reference HTML or anything like that (thanks for the good work getting/keeping it that way!), it might be nice if we could make a minimal subset which is referenced by ECMAScript, and then had a separate "WebIDL for HTML" document which added certain types, e.g., at a minimum anything where we can't take DOM out of the name
15:38:18  <tobie>Domenic: we could imagine having some kind of modifier at the class level for this.
15:38:22  <Domenic>Yeah
15:38:24  <Domenic>IDL references HTML in a few ways
15:38:31  <littledan>Domenic: For interfaces which are not exposed, used more in a mixin-like way, maybe we should keep using interface
15:38:43  <Domenic>https://heycam.github.io/webidl/#index-defined-elsewhere
15:39:47  <Domenic>It just seems strange to want to create a new IDL language because the existing one has bad surface syntax
15:39:57  <Domenic>And then learn all the lessons that the original had to learn, all over again
15:40:16  <littledan>most of the references seem to be in the examples, which I think should be fine
15:40:24  <Domenic>I'm especially bemused by wanting to change extended attributes to use decorator syntax when they are not decorators
15:40:34  <Domenic>The ones in the second column are more ingrained though
15:40:51  <littledan>I don't think square brackets will fly when we have computed property names
15:40:53  * brabquit (Quit: ERC (IRC client for Emacs 25.3.1))
15:41:05  <Domenic>I think they're fine, there's no ambiguity.
15:41:16  <littledan>seriously, I think surface syntax one way or the other is the most likely reason we'll fail to make progress
15:41:27  <Domenic>I think that's true if you make it your hill to die on.
15:41:32  <littledan>I'm fine proposing something initially which is just WebIDL but I'll be shocked if this is OK for the committee
15:42:09  <littledan>if we can make changes to WebIDL surface syntax like we've been discussing, I think it would be a lot easier
15:42:57  <Domenic>I'd be surprised if others on the committee found your particular surface-syntax issues high priority
15:43:09  <Domenic>But committee-guessing is fraught with peril so who knows.
15:43:30  <Domenic>(For example, I think the use of the term "attribute" and "readonly attribute" for getter/setter and getter properties is much more problematic.)
15:43:33  <littledan>So far, all of my guesses that the committee will not object on this or that basis have been wrong
15:43:51  <tobie>who's in the committee?
15:44:05  <littledan>yeah, I was thinking we should use JS get/set syntax for those as well, but they didn't come up in my example
15:44:42  <littledan>tobie: A lot of people, see https://github.com/orgs/tc39/people
15:45:19  <Domenic>littledan: would you want data properties to be expressible in this IDL too?
15:45:36  <littledan>it will be hard enough to push for any shared infrastructure with web specs at all; you know that that has seen a lot of resistance. When it turns out that classes are called interfaces because CORBA, I don't think it'll help at all.
15:45:39  <littledan>Domenic: Yes
15:45:59  <Domenic>littledan: OK, then I think we are headed for a bigger conflict, where I don't like having IDL with no normative implications.
15:46:03  <littledan>we have RegExp.lastIndex
15:46:10  <littledan>what do you mean, no normative implications?
15:46:20  <littledan>of course we'd change IDL to accommodate this if we use IDL
15:46:22  <Domenic>I mean, the normative spec text needs to set those properties anyway
15:46:26  * caridyquit (Remote host closed the connection)
15:46:29  <Domenic>This is like the return types issue
15:46:42  <Domenic>Where the normative spec text says what is returned anyway
15:46:46  <Domenic>The IDL ends up just being documentation in both cases
15:46:51  <Domenic>Which I am not a fan of at all
15:46:54  <littledan>I'm fine with being flexible about this
15:47:19  <littledan>my intuition was to represent it (isn't it nice to have things documented in headers?) but we could leave it out
15:48:08  * caridyjoined
15:48:57  <littledan>but my first question for using WebIDL would be, would WebIDL be OK adding enough to represent the JS builtins decently (maybe including things like doing lastIndex outside of IDL), or would there be too much resistance to even getting started with the basics like non-enumerable methods?
15:51:27  * caridyquit (Remote host closed the connection)
15:51:42  <Domenic>I think non-enumerable methods is pretty easy
15:51:48  <Domenic>You can just define your own extended attribute
15:52:00  <Domenic>[NonEnumerableMethods] interface RegExp { ... }
15:52:08  <Domenic>Now, whether we want to make that easier...
15:52:09  * caridyjoined
15:52:14  <Domenic>(easier/prettier)
15:52:34  <Domenic>esclass RegExp { ... }?
15:52:57  <Domenic>Oh, another big benefit of any IDL system is that we could automatically generate brand checks
15:53:17  <Domenic>https://github.com/tc39/ecma262/issues/354
15:54:43  <Domenic>I guess that's another modification you need, is for those methods that *don't* come with brand checks
15:54:47  <Domenic>Hmm
16:10:22  <annevk>It'd be good to enumerate what's missing
16:10:42  <annevk>Also, if you put data properties in IDL, wouldn't that at least tell you whether they're configurable and such so you don't have to define that again in prose?
16:11:13  <annevk>As for return values, you could always use "any" I suppose, but it's worth asking implementers
16:12:05  <tobie>As far as I'm concerned, convergence between ES and WebIDL is desirable. I don't think there would be pushback to include the necessary infra in WebIDL to support ES.
16:13:29  <tobie>I understand concerns about aesthetics, but I also want to balance that with the resources needed to make those changes, and the social capital burnt by forcing downstream specs to modify their WebIDL syntax without any benefits from them.
16:13:48  <tobie>s/from/for/
16:14:38  <annevk>Well, it's not "without", the idea is that they'll become more readable
16:15:22  <tobie>annevk: I'm not too sure that's a real concern for every editor, tbh. But yeah
16:15:42  <annevk>tobie: well they're less important than the other constituencies, so...
16:17:01  <tobie>annevk: I agree, but they're the ones doing the work. I'm not saying it's impossible, just that it has to be concerted and properly marketed for editors to understand the value
16:17:19  <tobie>Alternatively, some of these changes could be automated at the tools level
16:18:14  <tobie>e.g.: [ExtAttr] => @extAttr (regardless of whether this is something we _actually_ want to be doing
16:18:36  <annevk>I guess, thus far I haven't seen much opposition from editors to align with IDL changes
16:18:45  <annevk>E.g., when we asked everyone to add [Exposed]
16:18:53  <tobie>Agreed.
16:19:07  <tobie>But I'm not seeing the same enthusiasm for mixins
16:19:14  <tobie>Which I find weird
16:19:34  * caridyquit (Remote host closed the connection)
16:19:40  <annevk>Mixins requires tooling support which isn't getting done
16:19:50  <tobie>annevk: oh, that's a good point
16:19:54  <annevk>So yeah, that's a blocker of sorts for changes
16:20:12  <tobie>Well, this is something we have to get better at.
16:20:15  <annevk>I think if we could have an exhaustive list of changes and make them all at once that would also help a lot
16:20:23  <tobie>yes
16:20:27  <annevk>E.g., not rename DOMString this week and double next week
16:20:52  <tobie>Let's open an issue on heycam/webidl and see where that would take us.
16:22:17  <tobie>littledan, care to file? (like that you can continue editing it afterwards, as I don't think I have the privileges to add you as a repo collaborator)
16:30:21  * caridyjoined
16:33:26  * nmostafachanged nick to nagy
16:51:23  <littledan>tobie: Filed https://github.com/heycam/webidl/issues/484 and https://github.com/heycam/webidl/issues/485
16:53:08  <tobie>littledan: yes I saw. Thanks!
16:53:27  <Domenic>Yeah, why are mixin toolings not done, I really want to change that in all the specs :)
16:54:29  <littledan>I think it'd be great to have someone from the WebIDL community give a presentation to TC39 about how WebIDL could work for them, if anyone has the opportunity to look into these issues in detail
16:54:29  <tobie>:D
16:54:38  <littledan>s/them/ECMAScript/
16:55:06  <Domenic>I could do that, although I'd need more background on why this is suddenly an urgent problem
16:56:44  <littledan>I'd like to look into expanding the JavaScript standard library. I had a presentation about it at the last meeting, though it fell off the agenda
16:57:35  <littledan>if you look at the ECMA 402 specification and proposals to change it, there's a real diversity of how superficial bindings things are done. We're trying to change from an old style to a new, ES6-like style, but reviews are very difficult and specification authors accidentally diverge from the recommended pattern
16:58:41  <littledan>I think the only reasonable way forward is to have more concise ways to specify the right way, that doesn't require auditing mountains of copy-pasted text to figure out what's going on
16:58:58  <littledan>should be better for spec authors, reviewers and implementers
16:59:31  <littledan>we've been getting by now by just not expanding the standard library much, but then where we have, it's been unnecessarily divergent from common patterns
17:00:24  <annevk>Sounds familiar 😊
17:01:31  <littledan>Bradley Farias is interested in taking on the work to manage the project to figure out what should go in the standard library (hopefully with lots of JS developer input), but the IDL part is a separate project
17:02:27  <annevk>FWIW, sign me up for convincing anyone dreading syntax changes
17:03:14  <tobie>Yeah, I'm not too concerned about that either. It's essentially a resource issue.
17:03:51  <annevk>Domenic: I think this is the next big step in JS <> Web Platform harmony
17:04:58  <annevk>Massive long term benefits in describ
17:05:19  * jwaldenjoined
17:05:28  <annevk>ing classes the same way
17:22:41  * nagyquit (Ping timeout: 260 seconds)
18:10:55  * jowequit (Ping timeout: 260 seconds)
18:52:25  * pmdartusjoined
19:52:25  * nobsojoined
19:56:53  * nobsoquit (Client Quit)
19:58:20  * nobso_joined
20:00:40  * marxo_quit (Read error: Connection reset by peer)
20:00:46  * nobsojoined
20:01:24  * marxo_joined
20:03:01  * nobso_part
20:22:59  * nagyjoined
20:31:27  * pmdartusquit (Ping timeout: 240 seconds)
20:55:17  * nobsoquit (Quit: nobso)
20:59:47  * pmdartusjoined
21:01:07  * pmdartus_joined
21:01:08  * pmdartusquit (Read error: Connection reset by peer)
21:26:36  * marxo_quit (Quit: Leaving)
21:26:49  * marxo_joined
21:26:51  * marxo_changed nick to marxo
21:36:47  * nagyquit (Ping timeout: 255 seconds)
21:52:44  * nobsojoined
21:52:49  * nobsopart
21:58:15  * nagyjoined
22:21:42  * marxoquit (Ping timeout: 260 seconds)
22:39:20  * nagyquit (Ping timeout: 255 seconds)
22:45:20  * pmdartus_quit (Ping timeout: 248 seconds)
22:59:00  * pmdartusjoined
22:59:56  * pmdartusquit (Remote host closed the connection)
23:00:21  * pmdartusjoined
23:16:51  * pmdartusquit (Quit: Leaving...)