Hyeseong Kim

It will not work with transpilers like esbuild or Babel. Even if use tsc, it hurts the possibility of tree-shaking of build artifacts.

> It will not work with transpilers like esbuild or Babel. OK, it's outdated. @babel/plugin-transform-typescript and esbuild both support transpiling TS namespaces. However, it is not "fully" supported, and it...

You mean only create `.d.ts` files for `.bs.js` instead of TS wrappers? I think that would make sense if we make the JS representation more directly usable. GenType is actually...

> What about the opportunity of generating .d.ts files? I assume it would simplify a lot of things. But it's just an assumption. According to this comment, I'm drawing a...

ES proposal "module declarations" (currently stage 2) could be more proper target https://github.com/tc39/proposal-module-declarations

I think overwriting would be another feature. If we can check the type is exactly the same, we can omit one safely, I guess

you're right. And requiring type explicity for operators breaks compatibility, and falling back to the int operator ([which is how F# does](https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/arithmetic-operators#operators-and-type-inference)) doesn't add much benefit 🤔 I believe explicit...

I understand the tooling side is important, but tooling doesn't solve all syntax complexity issues (e.g. Rust) The difference between `+`, `+.`, `++` is the feedback I most often hear...

This is already implemented for comparators lik `==`, ``, etc ```res // these are fine let _ = 1 > 2 let _ = 1.1 < 2.1 // type error...

If the signature is omitted, it defaults to `int`. This can make some signature mismatch noise when writing implementation. For convenience we can reuse the coercion operator: `(someVar :> bigint)...