blob: c0ee6c6857608cb801c11cb85f1d703b900ab06e (
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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
"since versions" for symbols
============================
Token syntax
------------
Most compact, but harder to implement:
1.2
Easy to implement:
"1.2"
@1.2
Syntax alternative 1
--------------------
type T since 1.2 = struct {
}
func f() since 1.2 -> void
pros:
cons:
- a detail that is easy to miss during code review
- needs separate syntax for type/data/functions
Syntax alternative 2
--------------------
since @1.2
type T = struct {
}
func f() -> void
pros:
+ less repetition
+ easy to read
+ easy to implement
cons:
- related function can get spread out
- easy to miss newer (and possibly better) APIs
- easy to miss that "since" keyword if there are many symbols in a version
- confusing if the since and the symbol are on adjacent lines
Syntax alternative 3
--------------------
since 1.2
type T = struct {
}
since 1.2
func f() -> void
pros:
+ easy to read
+ easy to implement
cons:
- one extra line for each symbol
- confusing if the since and the symbol are NOT on adjacent lines (but that can be forbidden)
Syntax alternative 3
--------------------
since 1.2 type T = struct {
}
since 1.2 func f() -> void
pros:
+ easy to implement
cons:
- long lines
- makes it harder to visually find a certain symbol
Syntax alternative 4
--------------------
type T@1.2 = struct {
}
func f@1.2() -> void
pros:
+ compact
+ easiest to implement?
+ could allow overriding of symbols also!
cons:
- might be confusing for new users?
should @xxx be required even for the initial version? might be a good idea, to indicate that the ABI is stable
this syntax could be extended, to allow for deprecation or deletion of symbols:
deprecate T@1.2.1
delete T@1.3
(if the system ABI allows it, it would be possible to extend this to *changes*
of symbols also, but that would limit portability)
references to versioned symbols.
for example:
type T@1.1 = struct { ... }
type U@1.2 = struct {
ref T@1.1 t
}
for now, it could just be implemented as normal identifiers, with some extra
information about the version in the IdentDecl
syntax alternative 5
--------------------
type @1.2 T = struct {
}
func @1.2 f() -> void
pros:
- easy to implement (along with alt. 2)
- readable (version is not "inside" definition)
cons:
- makes searching harder
this can also be extended with deprecate/delete:
deprecate @1.2.1 type T
delete @1.3 type T
Syntax alternative 6
--------------------
versionsection @1.2
type T = struct {
}
func f() -> void
--or (@@@ is used by diffs)--
@@1.2
type T = struct {
}
func f() -> void
pros:
+ less repetition
+ easy to read
+ easy to implement
cons:
- related function can get spread out
- easy to miss newer (and possibly better) APIs
- easy to miss that "since" keyword if there are many symbols in a version
|
