atomic

create a String from this instance. Unless redefined, `a.as_string` will
create `"instance[T]"` where `T` is the dynamic type of `a`

Perform a bit-wise comparison of the value contained in this atomic and
`expected`. In case both values are equal, replace this value with `new_value`.

returns true, if successful

Perform a bit-wise comparison of the value contained in this atomic and
`expected`. In case both values are equal, replace this value with `new_value`.

returns the old value, independent of whether the old value is bit-wise
equal to `expected` or not.

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 hierarchy of types. So for Type values, dynamic_type is redefined
to just return Type.type.

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.

Does the current system permit racy accesses to the value of type T
stored in this atomic?

This is typically true for ref values and for small primitive types
such as `i32`, `f64`, etc. while this is typically not the case for
more complex types such as `point(x,y i64)`.

read the value stored in this atomic and do not care about synchronization.

In case of concurrent write operations, the result that is read may be
outdated. In the presence of concurrent writes and no synchronization,
out-of-thin-air values are possible (see https://dl.acm.org/doi/10.1145/3276506).

In general, this is useful only for debugging or monitoring purposes where
occasionally wrong random results are acceptable.

write a value in this atomic and do not care about synchronization.

Note that in conjunction with `racy_read`, this might create arbitrary
out-of-thin-air values.

read this value in a way that is atomic with respect to write operations
performed by concurrent threads

unwrap this atomic value

write this value in a way that is atomic with respect to read and write
operations performed by concurrent threads

string representation of this type to be used for debugging.

result has the form "Type of '<name>'", but this might change in the future

There is no dynamic type of a type instance since this would result in an
endless hierarchy of types, so dynamic_type is redefined to just return
Type.type here.

Is this type assignable to a type parameter with constraint `T`?

The result of this is a compile-time constant that can be used to specialize
code for a particular type.

is_of_integer_type(n T : numeric) => T : integer
say (is_of_integer_type 1234) # true
say (is_of_integer_type 3.14) # false

it is most useful in conjunction preconditions or `if` statements as in

pair(a,b T) is

=>

or

val(n T) is

name of this type, including type parameters, e.g. 'option (list i32)'.

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.

NYI: Redefinition allows the type feature to be distinguished from its normal counterpart, see #3913

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`.