Skip to content

Limitations

Daniel Wirtz edited this page Mar 8, 2019 · 8 revisions

Compiling untyped JavaScript to WebAssembly doesn't make sense because it would ultimately result in shipping another (slower) JavaScript runtime that runs within a JavaScript runtime.

Instead, AssemblyScript focuses on where WebAssembly excels and does not support falling back to super dynamic features of JavaScript that cannot be efficiently compiled ahead of time:

Mandatory types

  • There are no union types because everything must be statically typed by design.

  • Types like any or undefined cannot be represented for the same reason.

  • Nullable types must be reference types, e.g. ClassType | null.

  • Functions must have a return type annotation.

  • Variables and function parameters must either have a type annotation or an initializer.

    • If the initializer is an integer literal, i32 is assumed when it fits into 32-bits, otherwise i64 is assumed.
    • If the initializer is a float literal, f64 is assumed.
    • Otherwise the initializer is evaluated to obtain its type.
  • Optional function parameters require an initializer.

Details

  • The const and static readonly keywords currently work similar to static const in other languages and require a compile-time constant initializer while otherwise falling back to a mutable variable.

  • When calling an exported variable-length arguments WebAssembly function from JS, e.g.

    export function add(a: i32 = 1, b: i32 = 2): i32 {
      return a + b;
    }

    the actual number of parameters of the call must be specified explicitly because there is no equivalent to arguments.length on the WebAssembly side. Example:

    exports._setargc(0);
    exports.sum(); // 3
    
    exports._setargc(1);
    exports.sum(2); // 4
    
    exports._setargc(2);
    exports.sum(2, 3); // 5

See also: Status / Roadmap

You can’t perform that action at this time.