My 5c is that we should avoid reusing that trick. In my view it just makes the code more complicated and hard to follow for little gain.

There are currently about 60 files that usequerySelector. Adding a safe version for each element type could result in significant duplication.

Well, usinginclude creates that same duplication in the compiler anyway (include is a copy paste in the compiler). It's not in theReScript source files, but it'll be the same duplication in the output. And the output will probably be worse and harder to follow.

What about just using functions? Some internal function that takes a classifier or similar for each use case. Then we can just partially apply that same function in all relevant places. If we worry about duplication.

I don't think I mind duplication, but in this case, there is practical side.
I would add about 60 helpers for type safequerySelector access and would need to add those in 60 files.
Theinclude trick makes this that second part easier. Especially if we revisit bindings.

What about just using functions? Some internal function that takes a classifier or similar for each use case. Then we can just partially apply that same function in all relevant places. If we worry about duplication.

Could you give an example maybe?

Just so I understand correctly - you mean each of these 60 files get 60 variations of querySelector? So we have 3600 bindings to queryselector essentially?

Yeah, so you havedocument.querySelector which returns an element.
In this first example I've added aquerySelector_htmlCanvasElement helper to the document module.
But any HTMLElement interface has thequerySelector method as well, because of theElement inheritance.

The way it is currently set up is thatHTMLButtonElement for example, currently has a@send querySelector taking anhtmlButtonElement as first argument. This is to avoid that the user would need to "downcast" thehtmlButtonElement to anelement before they can usequerySelector.

@zth I've added an example to illustrate this in374f47c