[gethly]

> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {}

It should be

  fn foo(n i32, m i32) (i32, i32) {}

It will also allow future implementation of named returns, like in Go:

  fn foo(n i32) (a i32, b i32) {}

As for semicolon, that is needed only if you have inline expression:

  for (;;;) {}

Or inline block, like in Go:

  if foo := a + b; foo > c {}

[exceptione]

  > fn foo(n i32, m i32) (i32, i32) {}

But now consider returning a function with type¹

  Foo<T<string, T2>> -> (bool -> IDictionary<string, T3> -> i32 -> T3) where T2 : T3

even if you leave out the latter type constraint, I think it is hard to avoid undecidable ambiguity.

  fn foo(n i32, m T2) (????) {}

You quickly get ambiguity due to type parameters / generics, functions as arguments, and tuples if you don't syntactically separate them.

Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical.

____

1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.

[gethly]

This is pointless discussion as Go has all of these things already implemented, so there is no point in going backwards.

[exceptione]

The point is that a (new) syntax for any language needs to support any such implementation. The language implementation itself is not the point.

[gethly]

Yes, and I am saying Go has already solved all of this and it makes little sense to deviate too much from its syntax.