aboutsummaryrefslogtreecommitdiffhomepage
path: root/notes/generics_syntax_2022-01-10.txt
blob: 00b0feab2518945fc22a3d1169564d2e9132bfc1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

Generics syntax and refs
------------------------

I think refs/non-refs should be explicit:

    type List<ref T> = private

    ref List<ref SomeStruct> list1
    ref List<ref int> list2
    ref List<int> list3
    #ref List<uint64> list4

list1 contains references to SomeStructs
list2 contains references to ints (should this be allowed?)
list3 contains ints directly (where the pointer would be, but padded to the correct size)
list4 is not allowed since it would not work on 32 bit platforms

Optional types and generics?
----------------------------

Should it be allowed?
Where should the "none" be allowed? (We only have one "none" value)
- either in the paramter, or in the definitions, e.g:

    # ---- Either this: ----
    type Entry<ref T> = struct {
        ref? T thing
    }
    func get_thing(ref Entry<ref T> entry) -> ref? T

    ref Entry<ref Something> entry = ...
    # "none" if absent.
    # a "none" value cannot be placed in "entry".
    ref? Something st = entry.get_thing(entry)


    # ---- OR this: ----
    ref Entry<ref? Something> entry = ...
    # none if a "none" value was put into the Entry,
    # never none otherwise.
    ref? Something st = entry.get_thing(entry)

Special solution for optional values
------------------------------------
Allow several levels of none values using low values (like 0...255)

This has a performance impact, though, because taking the "value" of an
optional type requires a check whether it is less than 255, and if so,
an decrement operation.

An alternate solution is to always decrement!
This breaks conservative garbage collectors (and makes debugging etc.
a bit harder), but otherwise it is a very simple solution.

Even comparisons between none values should work, because two data items can
only be compared if they have compatible types (= same base type + same number
of nested optional types)
(But on the other hand, comparisons of raw optional values is more likely to
be unintentional than not.)

But the simplest option is of course to simply forbid nested optional types.