Type hierarchy.txt

This document describes an hypotetical type hierarchy for a non-existing environment.
It has been inspired by the CLR, JVM, and some IRC conversations.

Type tree:
----------

Any
    Void
    Value
        Primitive
            Int8
            UInt8
            Int16
            UInt16
            Int32
            UInt32
            Int64
            UInt64
            Float
            Double
            Char
            Pointer<T:Value>
        Struct
            ImmutableArray<T:Any>
                String : ImmutableArray<Char>
                Array<T:Any>
                ArrayView<T:Any>
            Enum
                <user enums>
            <user structs>
    Reference
        Box<T:Value>
        Object
            Nullable<T:Value>
            <nullable user types>
        Optional<T:Any>
        <non-nullable user types>

Remarks:
----------

Object is not the root because Object are commonly seen to be able to store things by reference, so having them at the root means Value types "lose" the reference status.

Void has only one value -- `void`. Casting anything to Void is valid, but discards the value. A Void field has no length, a Void variable has no storage, a Void parameter does not exist on the stack. This allows generic types to have a flexible parameter that can be discarded.

Reference can have new instances of it created, and each instance will have a different reference. This reference could be used for synchronization purposes.

Object can be null, can have new instances of it created, and each instance will have a different reference. This reference could be used for synchronization purposes.

Strings are immutable arrays, and arrays have fields (length), so they belong under Struct, along with Enums.

I put Enums under struct because although I prefer enums in the style of C or C#, I also like Java-style "collections of object values" concept.

All types can have methods, but Reference is the root of all the things that can have virtual methods.

Arrays are structs, with value semantics and inlined by default. By-ref arrays and strings would simply be Nullable<Array<T:Void>>. Indirectly, this allows strings and arrays to be contained in a constant pool, without this constant pool having to rely on special "hacks" to be accessed: the pool is simply a compiler-generated readonly struct.

ArrayViews: Maybe only immutable? Otherwise needs Copy-On-Write semantics.

Pointers are considered value types (the address of the pointer is a value), but they can be dereferenced so in some ways they behave like references. I put them under primitives as they are treated like special numbers.

Default values: 
    Primitives: zero
        Char: nullchar (codepoint 0)
    Structs: all fields to their respective default values
        Arrays: length must be known at compile time, contents will be defaulted to their type's default
    Non-nullable References: there's no "default reference", one must be provided by the implementation.
        Boxes: the default value will correspond to the box of the contained type's default value.
    Objects: null (which does not need to be represented as a number 0)
    Pointers: nullptr (a pointer of the given type which points to the memory location 0)