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.