| 01:21 | <Rick Waldron> | Do people remember the reasons why named argument syntax was rejected in JS? A la I don't remember why, it was dead before I ever started attending meetings. Either way, it's a non-starter now because...
|
| 01:22 | <Rick Waldron> | Mathieu Hofman: to your point ^^
|
| 01:23 | <Rick Waldron> | That Forbidden Extension was written exactly for the case you mention |
| 02:18 | <jschoi> |
|
| 02:42 | <bakkot> | strictly speaking, forbidden extensions constrain implementations, not us. we could write this into the spec and then implementations could ship it and that would be kosher. the point (as I understand it) is to prevent stuff like happened in the earlier eras when browsers would ship new syntax without it being in the spec (like function declarations in blocks, for example), and then we'd be stuck with it forever |
| 02:43 | <bakkot> | that said, we probably should not ship param: x unless it means roughly what it does in TS. |
| 02:49 | <Justin Ridgewell> | Does TS have param: x at call sites? I thought it was only function definition |
| 02:51 | <bakkot> | yeah, true |
| 02:54 | <Mathieu Hofman> | wouldn't you need at definition too for named argument? I understand you may not need it for explicit receiver |
| 02:55 | <Mathieu Hofman> | (Btw, I actually like that TS unlike Flow has the ability to type the this in function declarations, I wish it was more thoroughly leveraged though) |
| 10:29 | <yulia> | re groupBy Justin Ridgewell we have another report involving the sugar.js library: https://github.com/webcompat/web-bugs/issues/98458 |
| 14:37 | <Rick Waldron> | Huh! I had not known this was a thing. When was it added? Is it specifically to accommodate future ES type-like annotation, or is it specifically for ES extensions like TypeScript and Flow…? |
| 14:39 | <jschoi> |
|
| 14:39 | <jschoi> | There it is, hmmm. |
| 14:40 | <jschoi> | I’m reminded of rbuckton’s withdrawn request to reserve @@ syntax for extension languages’ decorators. |
| 14:41 | <Rick Waldron> | strictly speaking, forbidden extensions constrain implementations, not us. we could write this into the spec and then implementations could ship it and that would be kosher. the point (as I understand it) is to prevent stuff like happened in the earlier eras when browsers would ship new syntax without it being in the spec (like function declarations in blocks, for example), and then we'd be stuck with it forever |
| 20:19 | <ljharb> | fwiw it's never been true of those systems (maybe flow, but i haven't looked at it in awhile), but i think it's still a stated goal |
| 22:39 | <gkz> | (Btw, I actually like that TS unlike Flow has the ability to type the |
| 22:44 | <Mathieu Hofman> | Is that new? Last I checked, and according to https://github.com/niieani/typescript-vs-flowtype#declarable-arbitrary-this-in-functions-outside-of-objects, it was a TS only feature |
| 22:45 | <gkz> | that file was last updated 2 years ago |
| 22:46 | <gkz> | I would consider it largely inaccurate and would not use it as a source of information |
| 22:47 | <Mathieu Hofman> | Well arguably I've not looked at flow closely in about a year. But I do not remember about this feature. Wondering when it was added. Maybe we were stuck on an older flow version in the codebase I worked on at the time. Anyway, glad it's there now, and I retract that specific flow complaint |
| 22:49 | <gkz> | Improved typing of this was announced last year: https://medium.com/flow-type/sound-typing-for-this-in-flow-d62db2af969e |
| 22:50 | <Mathieu Hofman> | Just saw that, yeah that's after last time I looked into flow |
| 22:51 | <Mathieu Hofman> | And it looks like flow is being a lot stricter about this than TS, which is a + IMO |