blob: d9c9f2f415f062c6bacbd4891e023dffd9700f25 (
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
|
* "func" or "ref func"?
# XXX or should "func" automatically add a reference?
# - in that case "func IDENT" could mean "function pointer of type in typedef named IDENT"
# while "func("... could mean "function pointer of type given in-line"
# XXX compare this with strings:
# - "str" is implicitly a reference (but single-char strings can be stored inside the pointer)
# XXX also, "ref func ..." is NOT compatible with "ref any"
# with "func IDENT": how to define functions that can be pointed to?
# - should it happen automatically?
# if so, a function could have multiple named types.
# (e.g. "func SortFunc" and "func SubtractFunc")
# - should it somehow be done explicitly at the place of definition?
# for example:
# func sort_things[int](int a, int b) -> int callback SortFunc
# - generic funcs?
# - how about types like uint64 (or perhaps even uint32)?
# these types might not fit in a pointer.
# should those be passed by reference?
# that means that lifetimes need to be handled.
# - optimally, those would be passed by reference in the
# abtract machine, but platforms should be able to
# optimize those.
# - that means that comparing the addresses must not be
# allowed. (and this could apply to refs in other situations
# also. perhaps there should be a "unique"/"addr" attribute
# that makes address comparison allowed?)
# - should it be done in the interface?
# could this allow aliasing optimizations?
# - e.g. if we know that func X can only be called as a SortFunc?
# - this kind of optimization should happen with other types as well,
# which also means that taking a "ref int" to a "ref AliasOfInt"
# should perhaps not be allowed (but it might work when the pointer
# target is constant)
|
