blob: 9ff8264912691648df67f233d0063b102e6aab28 (
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
|
tiny (w/o explicit types):
f a,b
f(a,b)
func f(a,b)
func f a,b
oneline:
f(int a, bool b) -> int
func f(int a, bool b) -> int
multiline (types-then-names):
func f
int a
bool b
return
int ret
end
multiline (names-then-types):
func f
a: int
b: bool
return
ret: int
end
- the return section could be confused with the code section :(
multiline, without indentation:
func f
a: int
b: bool
return
ret: int
end
Type inference _can_ be ok if it is syntactically or locally inferrable.
This helps both reviewers and the compiler (as well as compiler error
handling).
This can be things like:
- global rules, e.g. i,j = int
- per-project rules that are repeated everywhere, e.g. srcloc = SourceLocation
and that aren't ambiguous in any way (e.g. based on actually called
methods in the function body)
Perhaps it could be allowed if at least two (of N) rules are satisfied.
|
