Fuzion Logo
fuzion-lang.dev — The Fuzion Language Portal
JavaScript seems to be disabled. Functionality is limited.

unit

unit

unit -- value to be used as result of features that do not return a result

NOTE: unit corresponds to type void in C, Java, etc.

unit is the preferred result type for features that return without producing
a result value. These are features that typically have an outside effect
such as

println(String s) unit => ...

or features that change the state of an instance such as

increment(delta i64) unit =>

The Fuzion language implementation automatically inserts code that returns the
unit value as a result of these features, there is no need for an explicit unit
result as in

increment(delta i64) unit =>

but it is allowed to return unit explicitly if desired.

Another application of the unit type are generic features when certain generic
values are not needed and can be ignored. An example could be a generic map
implementation map K V that maps values of type K to values of type V. Using
unit as the actual generic argument for V, e.g., map string unit creates a
map that stores no data for each key, which essentially turns the map into a
set of the map's keys.

The Fuzion library knows several different unit types. Another example is nil,
which is used as the alternative type in an option. This enables the use of
option void, which can store two distinct values, void and nil.

Other unit types in Fuzion are TRUE and FALSE.

The simplest syntax to create a value of unit type is an empty block '{}'. Note
that an empty tuple 'tuple' is a different unit value of a different type and
the syntax '()' is (at least for now) not supported.

Please note the fundamental difference between

red is {}
red => {}

The first declares a feature red that defines a new unit type red, the second
declares a feature red with result type unit, i.e., a synonym for unit as in

red unit => {}

The memory required to store a value of unit type is 0 bits, so you can use
plenty without worrying about space constraints. The Fuzion code generators
typically will not generate any code for returning or assigning a value of unit
type, so these are very efficient as well.

Functions

human readable string

redefines:

§
:
Any
 => 
Type 
[Inherited from  Any]
Get the dynamic type of this instance. For value instances `x`, this is
equal to `type_of x`, but for `x` with a `ref` type `x.dynamic_type` gives
the actual runtime type, while `type_of x` results in the static
compile-time type.

There is no dynamic type of a type instance since this would result in an
endless hierachy of types. So for Type values, dynamic_type is redefined
to just return Type.type.
§
:
Any
 => 
String 
[Inherited from  Type]
name of this type, including type parameters, e.g. 'option (list i32)'.
§
:
Any
 => 
String 
[Inherited from  Any]
convenience prefix operator to create a string from a value.

This permits usage of `$` as a prefix operator in a similar way both
inside and outside of constant strings: $x and "$x" will produce the
same string.

Type Features

Monoid that can be used whenever a monoid of the unit type is expected.
This is the case for example in some calls to `fold`-like features.

Since there is exactly one value of type unit, the operation, the equality
and the identity element of this monoid are canonically defined.
§
:
Any
 is
 
[Inherited from  Any]
Get a type as a value.

This is a feature with the effect equivalent to Fuzion's `expr.type` call tail.
It is recommended to use `expr.type` and not `expr.type_value`.

`type_value` is here to show how this can be implemented and to illustrate the
difference to `dynamic_type`.