The newest release of JS++ is now on the wild, and it wants to fix a big issue. “I promised a breakthrough for our next release,” says Roger Poon, JS++ lead designer and co-inventor of existing types in an official blog post. He delivered by announcing that this new 0.9 version includes a compiler that can analyze out-of-bounds errors at compile time.
Out-of-bounds errors occur when you attempt to access a container element that isn’t actually present in the container itself. “For example, if an array has only three elements, accessing the tenth element is a runtime error,” explains Poon. He says that these type of bugs have “plagued” computer science and programming since basically the beginning. Detecting these errors can be impossible at worst, slow at best, depending on the language design. Even worst is the fact that they often result in the application terminating.
Poon is proud about the advancements, and with reason. According to him, “there’s virtually no effect on compile times” with the solution they’ve come up with. In complex projects, JS++ 0.9 can perform out-of-bounds analysis with only a ±1-2ms (milliseconds) overhead.
Poon explains that they are prioritizing efficiency, especially after the previous release was such an important step forward in this regard (it delivered compile times that were 30% faster). Introducing new features now that would increase compile times again wouldn’t make much sense, so the team got to work. And the results speak for themselves: Poon provides test results that show that there’s virtually no performance penalty for dealing with out-of-bounds errors at compile time.
How are they doing this? Poon lays it out: “We achieve efficient analysis using traditional nominal typing. An existent type is no different from ‘bool’ or ‘unsigned int’ in JS++ in terms of type checking performance.” He says that while it’s true that you need to know the size of the array, you don’t need to know it at compile time. “Existent types describe whether a value is within-bounds or out-of-bounds. The rest is compiler engineering: bounds checking is delayed to code generation and Standard Library code rather than being performed in the type checker.”
0.9 also addresses nullable types, which “are a problem,” according to Poon. In essence, a null value is a value that technically exists but is actually empty. Meanwhile, undefined values do not exist at all. This enables differentiation between in-bounds values and out-of-bounds accesses. Nullable types can be the container element type when representing empty values are needed, but existent types are used only for representing out-of-bounds accesses and cannot be the container element type.
“We place heavy emphasis on compile times because we know long compile times hurt developer productivity,” Poon argued, adding that if used correctly, existent types should never get premature or unexpected program termination.