Version 0.6.0#

🚨Breaking change: Use => for lambda blocks instead of ;;#

To make the syntax possibly more familiar looking, lambda blocks now use thick arrows to separate the header from the body:

inerttoListBuilderWith { (key: K, value: V): Pair<K, V> =>
  new Pair(key, value)
}

Previously, ;; was used instead of =>.

Temper syntax still differs from JS arrow functions in order to accommodate the trailing block syntax.

Also new, When only parameters are explicit in the lambda block header, parens are optional, as in this example:

inertforEach { key, value =>
  builder.add(func(key, value));
}

Explicit parameter types also can be given without parens, so long as explicit return type or other components outside the parens are absent:

inert// The type of parameter *substring* is *String*.
this.substrings.join("") { substring: String => substring }

🚨Deprecated | Bubble syntax in favour of infix throws#

Previously, a function definition communicated that it could fail by including | Bubble at the end of its return type.

Other recent changes, to express nullable types as T? instead of T | Null did away with reasons for | as a type operator.

Now using | as a type operator issues a warning.

$ temper repl
$ let f(): Int | Bubble { 0 }
1: let f(): Int | Bubble { 0 }
            ┗━━━━━━━━━━┛
[interactive#0:1+9-21]@D: `|` is deprecated for types. Prefer `T?` to `T | Null` and `T throws F` to `T | Bubble`
interactive#0: void

The preferred syntax is now to use throws instead of |:

$ let g(): Int throws Bubble { 0 }
interactive#1: void
$ g()
interactive#2: 0

🚨Breaking change: Int is now Int32, and Int64 is new#

Before, Int semantics and sizing depended on each backend. Now, it's an alias for Int32, and it always has wraps on overflow for math ops performed in Temper-built code. Because of the change in backend semantics, there could be some change in behavior on some backends.

Int64 is now also available, and it also wraps on overflow.

Both types map to the most appropriate types available on each backend. No backend type mapping has changed for the Int/Int32 type, even though math operations are handled differently now on some backends.

This change enables more consistent semantics in Temper code, and it also looks toward future optimized CPU-native code support in languages such as Python.

🚨Breaking change: Multiline string syntax#

Previously, Temper used Python-esque triple quoted string syntax but with rules for stripping incidental spaces from the beginning and ends of lines.

inertlet s = """
  Two spaces stripped per line
  Including here
  Can't have """ here
  """;

Triple-quoted string syntax has changes so that there is no end delimiter, and there is a margin-character on each line.

let s = """
  "<-- That quote mark is not part of this line
  "But it means that we can have """ here without problem
;  // Since this line didn't start with ", the string ended.

Spaces (and tabs) are still stripped from the ends of lines, so use ${} if you need a line to end with spaces.

This change should make it easier to tell (once you know the rule) where a line starts, and make it easier to auto-format Temper code including code with syntax errors.

Licensing terms changed from EULA to OSS licensing#

Previous use of Temper tools was governed by an end user license agreement (EULA).

Old releases are still under the EULA, but this and new releases going forward are under open-source licensing, as is everything developed at https://github.com/temperlang/temper.

See the top level COPYRIGHT file for details of the new licensing.

When in doubt, if you have a copy of the command line tools and you want to know the licensing terms, running temper license at the command line will print the relevant info.