Open water-mizuu opened 1 year ago
@water-mizuu with switch expressions your example could be much shorter, and the signature of the function wouldn't have to be duplicated for each case, as is the case in your proposal:
int fibonacci(int v) => switch (v) {
0 || 1 => 1,
_ => fibonacci(v - 1) + fibonacci(v - 2),
};
I think a problem with this solution is going to be that the order of your function declarations now matter, which is not something we have today and is also not something I really want to start introduce to the language since it is going to be a major pain with e.g. imports.
I also agree with modulovalue that is is limited how much space you are going to save. But the main point is really that with a switch statement, the order of the checks are easy to observe compared to this new syntax where it becomes a lot harder.
Another problem is then also going to be IDE support where you today can click on a method and go to the declaration. How would that work with this new syntax?
I think a problem with this solution is going to be that the order of your function declarations now matter, which is not something we have today and is also not something I really want to start introduce to the language since it is going to be a major pain with e.g. imports.
I also agree with modulovalue that is is limited how much space you are going to save. But the main point is really that with a switch statement, the order of the checks are easy to observe compared to this new syntax where it becomes a lot harder.
Another problem is then also going to be IDE support where you today can click on a method and go to the declaration. How would that work with this new syntax?
Honestly, this wasn't really a well thought idea, I didn't even consider the fact that declarations now have order. However, I think the syntax would be a nice basis for future destructuring of parameters?
@water-mizuu Not sure about the syntax is good for parameter destructuring but I would recommend having that discussion in the following issue: https://github.com/dart-lang/language/issues/3001
This shouldn't allow overloading, and should just be treated as syntactic sugar. Of course, functions that use patterns should be consistent and have a bottom-definition / should be exhaustive. Example below:
This would be sugar for:
An example of function of potentially unsafe overloading:
This would mean that the functions must have the same signature, and is not fully fledged function overloading, but it's worth a discussion in my opinion.