Short-circuiting boolean functions: && and ||
The big win for users is the new short-circuiting
|| operators. Darklang previously used functions for
&&, which meant that both expressions were always evaluated. For example:
if false && fireTheMissiles would have fired the missiles, and you can now avoid that unfortunate outcome.
Like all things in Dark, this change is backward-compatible. Old uses of the
&& function calls still work as they did before (as does copy-pasted code, calls to existing functions, etc), but are marked as deprecated. A built-in command called
convert-to-short-circuiting can be used to automatically convert the old version to the new version.
New uses of
&& will use the short-circuiting versions by default. If you prefer the old version, you can call
This change turned out to be much bigger than expected and leveraged a lot of our recent internal work in ensuring we can carefully move the language forward without breaking existing user code, such as the "ClientTypes" and serialization testing work in Darklang Release 8. We feel really proud of our ability to change core language features such as the
&& operators without any risk to developers using Darklang!
Darklang has some character functionality built-in, and we're starting to expand it (a "character" in Darklang is a single screen-visible character, technically called an "Extended Grapheme Cluster"). We have added functions on characters, including:
We have also added the ability to add the
Char type in function parameters and return types.
Other user-facing changes
We've started using a new font (Source Sans Pro) in places where the monospace font was inappropriate, which will become our new default font in the future.
We've also added
List::partition_v0, expanding our experimental support for tuples, first discussed in Release 6.
We also had a lot of internal improvements. On the backend, we merged the old
fsharp-backend directories, started moving traces out of our DB and into Cloud Storage, removed old internal settings, and refactored
match patterns to create room for upcoming
let patterns. We've also added better serialization checking to prevent deploys which are not able to read user code (high risk: this would take the whole service down).
On the client, we have increased our usage of ReScript libraries for browser APIs, and increased our use of Tailwind.
Try it now