TC39 General
2022-03-10
plaintext logs
prev next
source on github
00:53
<Jack Works>
I like TypeScript, but I don't think that type comment proposal is a good idea...
00:53
<Jack Works>
the goal of that proposal, "make devs no need to transpile code" cannot be really achieved by this approach
00:54
<Jack Works>

for example, TS 4.7 has a new syntax, instantiation expression like this:

const numberSet = Set<number>;
const set = new numberSet(); // type: Set<number>
00:55
<Jack Works>
this syntax will somehow has ASI hazard if I don't write ;
00:56
<Jack Works>
To achieve the goal of this proposal "make devs no need to transpile code", everytime Flow, TS, ... adds a new Type level syntax, we need to cover that in the language
00:56
<Jack Works>
I don't think it's a good way to go.
00:57
<Jessidhia>
it’s intentionally incomplete, IIUC
00:57
<Jessidhia>
it can’t cover enums for example
00:57
<Jessidhia>
I think the idea is just to take the : reserved token and make it comment-like instead
00:58
<Jack Works>
so how does that make devs no need to transpile code? If we only have : style types
00:59
<Jack Works>
I write a lot generics, conditional types, union/conjunction types, etc
01:00
<bakkot>
it definitely lists lots of things beyond :, but also yes it is not everything in TS
01:01
<bakkot>
given that this is just for development anyway, I wonder how hard it would be to make a chrome extension which rewrote typescript to js so developers could use that
01:03
<Jack Works>
it's very hard. From Jan 2022, you cannot upload new Manifest V2 extension, and you need webRequest API to modify network requests.
01:05
<bakkot>
oh right, boooooo
01:05
<Jack Works>
it's very easy on MV2, you just get every request and parse the html and send inline JS to the transpiler (maybe also recompute CSP hash)
01:32
<danielrosenwasser>
For what it's worth, I believe the Python community recently tried to turn off the by-default reflective capabilities of type hints (due to the performance impact) and they had to pull the changes back.
01:34
<danielrosenwasser>
I write a lot generics, conditional types, union/conjunction types, etc
In these cases, you'd be able to leverage the full type syntax in a .d.ts file or parenthesize the syntax that you need
01:35
<danielrosenwasser>
Most of those types would be parsed at the top level, and parentheses/bracketing is your escape hatch
01:35
<devsnek>
i mean i haven't deeply investigated this obviously but i think fancy js engines that care about this sort of thing could make the cost of the strings only be paid if you actually use it, without a silly amount of effort
01:36
<danielrosenwasser>
FWIW we have a (tentative!) grammar https://github.com/giltayar/proposal-types-as-comments/blob/master/site/src/grammar-input.html
01:48
<danielrosenwasser>
So hey all, sorry I haven't had the chance to discuss the proposal more in this room - there's been a lot going on today! What I'll just say before I have to run is that we're just trying to make type analysis easier in JavaScript given how popular TypeScript has grown over the past few years. I think that Rob Palmer , Romulo Cintra and I extremely open to questions/comments/concerns/criticisms on all this. I'll try to be more available tomorrow/later this week if people want to discuss
01:49
<devsnek>
i think its very cool i will just be sad if we do not get any reflective capabilities on this given that this is a dynamic language
01:50
<Jack Works>
https://github.com/giltayar/proposal-types-as-comments/blob/master/site/src/grammar-input.html#L196
01:50
<Jack Works>
👀
02:05
<Jack Works>
i think its very cool i will just be sad if we do not get any reflective capabilities on this given that this is a dynamic language
I tried Typescript's metadata reflection type. It's tooooo weak, any complex type will be transformed to Object. It cannot express any complex type. Only classes and primitive types
02:06
<devsnek>
tbh all i'm asking for is strings
02:09
<Jack Works>
Even worse... How do you know those types are referring difference entities if their share the same name?
02:10
<Jack Works>
And if it contains complex structures, you need to parse them by yourself
02:16
<Jack Works>
my personal opinion on this proposal: it has an ambitious goal, but I don't think it will achieve the goal, and it's not worth to add so many syntax and all of them doesn't do anything; but if it cannot really do anything, real type check is not a path (web compat) or python style reflection (performance? and I don't like that either)
02:37
<bakkot>
i wonder how hard it would be to make a VSCode plugin that let you edit a file with flow-style type-comments (https://flow.org/en/docs/types/comments/) as if the comments weren't there
02:38
<bakkot>
that is, as if you'd written the contents of the comments inline
02:38
<bakkot>
so you could write let x: y = z but the file on disk would be let x/*: y */ = z
03:17
<Jack Works>
Then why not use compileOnSave to let ide just compile the file directly for you 🤔
03:26
<bakkot>
tsc is soooooo slow
03:26
<bakkot>
is the main reason
03:26
<bakkot>
though I guess you could set up esbuild instead
05:12
<Jack Works>
one possible usage of this is
05:12
<Jack Works>
engine can use type comment as the JIT hint
05:12
<Jack Works>
to get the better hint at the first time, don't need to guess
05:13
<Jack Works>
and if type mismatches, engine can still deoptimize
05:15
<Jessidhia>
that would require some sort of standardization for the type hints themselves, not only the syntax markers, though
05:16
<Jessidhia>
and number is not a good enough type hint for engine optimization
05:17
<bakkot>
also most types in most TS codebases I've seen are inferred, and the cost of doing the type inference is probably significantly more than the benefit you'd get from skipping some JIT warmup
05:17
<Jack Works>
well, at least you will type your function parameter when there is no contextual typing is available
17:23
<sirisian>
My greatest fear has become reality with this proposal. Locking the : syntax to comments forever. I blame phones for not being powerful enough.
17:25
<ljharb>
btw what is Hegel? it's referenced in the types proposal's issue comments a number of times but i've never heard of it before
17:25
<ryzokuken>
https://hegel.js.org/
17:29
<ljharb>
ok - so this one that has 73 downloads a week? https://www.npmjs.com/package/@hegel/cli
17:31
<ryzokuken>
seems like it, yes
17:31
<ljharb>
k, thanks
17:32
<danielrosenwasser>
i wonder how hard it would be to make a VSCode plugin that let you edit a file with flow-style type-comments (https://flow.org/en/docs/types/comments/) as if the comments weren't there
It ends up being the same thing as building the infrastructure for a type-checker that supports that
17:33
<danielrosenwasser>
or a language server that has to take the place of the default one, and do a bunch of rewriting to the TS language service, kind of what plugins do for .vue files
17:34
<Ashley Claymore>
Hegel uses the babel-parser with the flow-plugin. So from a syntax perspective it is the same as flow. I like that it is called out anyway :)
17:37
<danielrosenwasser>
or a language server that has to take the place of the default one, and do a bunch of rewriting to the TS language service, kind of what plugins do for .vue files
But I don't think that's the point really. There's a valid question of whether or not the format of JSDoc is the most painful part - but I think most of our team feel convinced that the issue is really around having to jump into an actual JS comment wrapped in /*..*/. It really doesn't feel that natural.
17:40
<ljharb>
Hegel uses the babel-parser with the flow-plugin. So from a syntax perspective it is the same as flow. I like that it is called out anyway :)
thanks, that's good context. it's fine to call it out but implying it's a third equal alternative seems a bit strange :-)
17:42
<Ashley Claymore>
Considering Flow has built in support for /*:: <type> */ syntax but Meta still decided to build direct support for parsing non-comment syntax types directly into Hermes (JS engine for react native) might be some evidence that they saw value in avoiding intermediate files?
17:43
<ljharb>
i think flow didn't start out with that support tho
17:43
<ljharb>
i distinctly remember asking someone on the flow team why it didn't, many years ago at a TC39 meeting, and then seeing a bit after that that such support had shipped
17:44
<ljharb>
(i guess the history there isn't relevant to hermes tho, since by the time hermes was created it def was supported)
17:51
<Ashley Claymore>
i think flow didn't start out with that support tho
yep, support added 2015 after being "one of our most requested features" https://flow.org/blog/2015/02/20/Flow-Comments/
17:52
<bakkot>
But I don't think that's the point really. There's a valid question of whether or not the format of JSDoc is the most painful part - but I think most of our team feel convinced that the issue is really around having to jump into an actual JS comment wrapped in /*..*/. It really doesn't feel that natural.

well, two things:

  1. It would feel a lot more natural if the comment were syntax highlighted properly
  2. the point of my VSCode plugin suggestion was that you'd edit the file as if the /* comment weren't there, thus getting rid of even that hurdle
17:55
<Ashley Claymore>
the main issue I've found with /* */ comments is they can't be nested
17:55
<Ashley Claymore>
for when I want to comment my types
17:55
<bakkot>
you can still use // though
17:56
<Ashley Claymore>
yep though they tend to be ignored by documentation generators
17:56
<bakkot>
I used flow-style type comments for a couple years and it wasn't really an issue
17:56
<bakkot>
ok but that's just a problem with the documentation generators
17:57
<danielrosenwasser>
i think flow didn't start out with that support tho
I don't really understand the significance there though - 2015 is just a year after Flow went public
17:57
<ljharb>
danielrosenwasser: yeah given that the question was about hermes, it's not relevant, i just missed that when replying
18:00
<Ashley Claymore>
ok but that's just a problem with the documentation generators
yes and maybe no? I've always seen it as // is for less official comments that don't make it to the documentation. And /** is the special signal for this is a doc comment
18:35
<danielrosenwasser>
So I would also like to point to Python which started out with type comments
18:35
<danielrosenwasser>
Type comments were okay, but clearly people wanted something a bit more ergonomic with a dedicated syntax
18:36
<bakkot>
python's type comments were significantly less ergonomic than flow's type comments, IIRC
18:36
<danielrosenwasser>
In what ways?
18:37
<bakkot>
just like
18:38
<bakkot>
one sec while I make sure I remember the syntax here
18:40
<bakkot>
def method(self, lst, opt=0, *args, **kwargs):
    # type: (List[str], int, *str, **bool) -> int
    body()

vs

function m(lst/*: string[]*/, opt/*: number*/, ...args/*: string[]*/) /*: number */ {
  bod()
}
18:40
<bakkot>
python's type comments aren't as bad as jsdoc but they're still not really how you'd want to write types
18:41
<bakkot>
you can't put them on individual parameters, and also you need to spell out type: for every single one
18:55
<danielrosenwasser>
I personally don't like the second one because you have to jump in and out of comments 4 times
18:56
<bakkot>
I agree it's moderately more annoying than just using typescript syntax directly, yes
18:57
<danielrosenwasser>

So we got the (tentative!!! - not written in stone) proposed syntax rendered

https://giltayar.github.io/proposal-types-as-comments/grammar.html

18:57
<ljharb>

when using jsdoc with tsc i usually go for something like

/* import('./types') */
function m(lst, op, args) { }