7 ms·
> 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 al
by gethly 10mo ago
> 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 10mo ago> 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 10mo agoThis is pointless discussion as Go has all of these things already implemented, so there is no point in going backwards.
- exceptione 10mo agoThe point is that a (new) syntax for any language needs to support any such implementation. The language implementation itself is not the point.
- gethly 10mo agoYes, and I am saying Go has already solved all of this and it makes little sense to deviate too much from its syntax.