Proposal. How about have two modes "typed strict" and "compatibility"?

[MaxGraey]

Assembly Script is superset of typescript that's mean it should have some compatibility with typescript if I right understand one of the main goal. In this case we might easily portable typescript code to AS with minimal changes. In other hand with WebAssembly we have got int64 arithmetics, atomic operations and etc.

For example in typescript parseInt return double with NaN when something wrong, but in AS we can return i64 which make sense, but we loose compatibility.

My propose is make two macro definitions as compile option modes or string hint. One of them is safe compatibility with JS/TS runtime and other produce code with all wasm capabilities.

Thought?

[dcodeIO]

Hmm, well, I understand the intention, but at the end of the day there'll always be some things that are not 100% compatible. Take array indexes for examples - we really shouldn't make these f64s.

But this makes me think: Maybe we shouldn't provide parseInt at all and just name the AS implementation i32/i64.parse, with a portable implementation that uses parseInt under the hood but coerces to i32s, without NaNs. Wdyt?

[MaxGraey]

Yes, as an option.
Also AS could provide two std libs for example just like C and C++ do it. I mean libc/cstdlib and libc++ but for TS/JS (compatibility) and for AS (with strong types)

[dcodeIO]

I see. What can be done today is adding a mechanism to specify the stdib path when invoking asc, making it possible to switch to another one, so everyone can experiment with alternatives. Would that be something you are interested in?

[MaxGraey]

Definitely "yes"

[dcodeIO]

While thinking of it I figured that this could also be used to extend on stdlib implementations. Replacing the default one could be --noLib --stdLib path/to/other while extending the default one could be --stdLib path/to/other.

[MaxGraey]

And may be better move stdlib out in separate package and repositaties in AssemblyScript organization? With libas and libts names for example

[dcodeIO]

I'd rather avoid that at this point in time. I already felt that all the packages the prototype had were unnecessarily complex to manage, especially since all these components are usually tightly coupled to a specific version of the compiler.

[dcodeIO]

Usage:

• --noLib --lib path/to/mylib to replace stdlib.
• --lib path/to/mylib to extend stdlib

Similar to stdlib this includes all top-level .ts files in compilation, and exposes their exports as globals.

[dcodeIO]

Closing this for now. Feel free to reopen if something else is required :)

[otabekgb]

Assemblyscript is my dream project, thanks for such a good project. I am trying to promote it wherever I can. But full typescript compatibility is the only way to get the whole ts/js ecosystem behind. Otherwise assemblyscript will remain a small island, nobody will try to change their code from standard typescript. We should make it seemless, as easy as possible. Why can't we use V8 API to evaluate/run dynamic language features? Also double should be default number type and other numbers should be exposed advanced users. Please take it serious, I want this project to be successfull

[MaxGraey]

full dynamic features is not possible now and will not expect in future so using any typescript code "as is" without minor modifications is not possible. We want stay independent from any host (and v8 as well) also it require some wasm features which not exists in MVP like anyref. But fully automatic or semi-automatic migration tools already building. See esmbly