Juraj Kirchheim
Juraj Kirchheim
It would be nice to have the ability to have a "custom module type" that takes precedence in module resolution. One concern is the number of lookups. It would be...
Example: ```haxe import sys.net.*; function connect(options) { var ret = new Socket(); ret.connect(options.host ?? Host.localhost(), options.port); return ret; } ``` In this case I would like `options` to be inferred...
I'd like something like `Context.storeTypedExpr` for types. In tink_macro this behavior is emulated per `@:genericBuild class DirectType {}` where the type is stored with a numerical id and then looked...
In tink_core there's a whole bunch of abstracts over functions returning promises such as [`Next`](https://github.com/haxetink/tink_core/blob/aea0dd2227d22156716c70561168765f6294de15/src/tink/core/Promise.hx#L307),[`Combiner`](https://github.com/haxetink/tink_core/blob/aea0dd2227d22156716c70561168765f6294de15/src/tink/core/Promise.hx#L338) and [`Recover`](https://github.com/haxetink/tink_core/blob/aea0dd2227d22156716c70561168765f6294de15/src/tink/core/Promise.hx#L332) where the `@:from` casts were never meant to be taken into account by...
It would be nice if one could use the server in a hybrid mode that uses the cache only for display/diagnostics and is ignored in any build (if the build...
Via e.g. `-D tink_core.catch_exceptions` a few try/catch barriers would be added: 1. in Promise.next/new/irreversible exceptions would be propagated as errors. 2. In `Callback.guardStackoverflow` (which is where almost all dispatching goes...
Currently spec and implementation are not aligned, in part because it is tricky to do (see `CallbackList` and consider what happens when disposing during invocation).
Currently it just sits there.
Because we can!