JS++ 0.9.1: Bug Fixes

The JS++ core is now down to 9 low-priority bugs after 3.5 years of engineering and 400k+ lines of source code thanks to our lead engineer, Anton Rapetov.

Building on top of our release of “existent types” to prevent out-of-bounds errors, we’ve had enough time for testing and feedback to discover that existent types work, and they will remain a cornerstone of JS++ going forward into the future.

This latest release, version 0.9.1, focuses primarily on bug fixes. We value disciplined engineering, and we wanted to pay back technical debts. However, despite the bug fix theme, there are a few notable features and announcements. I’ll highlight what’s new or changed, and the list of bug fixes will be at the end.


While we’ve had Console.log for a long time, it doesn’t include critical information on where the log message originated from. You might find the new Console.trace method more useful:

filename.js++:3:0: Now we have the original file location, line number, and column number for our logs!

Block Scoping

We’ve also had block scoping semantics for a long time. JS++ brings you high-performance block scoping — even in ECMAScript 3 environments.

In the latest version, block scoping is finalized and all corner cases should be covered. Specifically, we fixed code generation corner cases of lowering to the function scoping semantics of ECMAScript 3.

(We are keenly aware of the block scoping available in ECMAScript 3+ ‘catch’ blocks, which we addressed since the very first release of JS++ as being too costly in terms of performance. This is a gem of the ECMAScript specification that few people know about, and it highlights why you should trust our knowledge and experience – rather than choosing Microsoft just on brand name – going into the future.)

Existent Types

In the last version, 0.9.0, we announced existent types to prevent runtime out-of-bounds errors. In this release (0.9.1), we are doubling down on existent types and revising the rules based on experience, feedback, and re-design:

  • If type T has an implicit conversion to external, T+ also has an implicit conversion to external
  • The safe navigation operator (??) has a higher operator precedence. See the operator precedence documentation.
  • Relax getter/setter type rules for nullable and existent types
  • Disallow void+ and any usages of void except as a return type
  • Forbid external as a common type for int and string for the safe navigation operator (??). Thanks to user @h-h in the JS++ Community Chat for reporting this bug.
  • Fix error message when upcasting/downcasting in the context of nullable/existent types to make it clearer

Nested Generics with Generic Parameters

In previous releases, we had left nested generics (with generic parameters) unimplemented. Previously, the following code worked:

Array<Array<int>> arr1; // nested, non-parametric
Array<T> arr2; // non-nested, parametric

The latest version now enables nested generics with generic parameters:

Array<Array<T>> foo; // nested *and* parametric

Bug Fixes

Finally, here is a list of all the other bug fixes. There are a lot. The latest 0.9.1 release brings JS++ software quality to its highest level yet by addressing technical debt rather than delivering new features.


  • ‘foreach’ looping over external “array-like objects”
  • SyntaxError in generated code for generic functions/casting
  • Error message for super() on base class
  • Duplicated error messages
  • Line terminators in strings generated via escape sequences
  • Fix segfault when casting away nullable type of non-static field
  • Don’t raise a redundant error of accessing a parameter that was shadowed
  • Raise a special error “Re-declaration of parameter”, if a parameter was shadowed
  • Allow hoisting of static class fields across different classes in the same module
  • Do parameter and arity checking on new
  • Wrong line number for dot operator
  • Inaccurate error message for generic instanceof
  • Only one error message for method overriding when inheriting from generic class with non-existent argument


Software quality at JS++ has always remained high, and that’s a testament to the ability of our lead engineer, Anton Rapetov, and our engineering approach. In more than 3.5 years of engineering, we currently have fewer than 10 open bug reports in the core compiler.

Roger PoonRoger Poon
JS++ Designer and Project Lead. Follow me on Twitter or GitHub.