I’ve been upgrading some of my code base to support the new parametric functions syntax – I’m using such functions extensively, with return types declarations. My feedback is that if this has been a step forward for the compiler, it’s also a step backward for humans.
the function declaration no longer flows naturally. Before you’d have the function name and arguments first and the return type at the end. Which made sense - you could glance at a function and quickly see the list of arguments and the expected return type. Now you have to mentally peel off the
wherepart at the end of every function which adds a lot of noise.
you can no longer separate the arguments tuple from the return type with spaces. First, this is unexpected, because it works when you don’t have parametric functions but errors with parametric functions. Second, it makes the function declaration even harder to read, with everything gobbled up in one long line. Third, you end up with things like
(i::Int)::Intwhich makes me dizzy.
EDIT: [I understand the situation will get even worse, by soon having to wrap function declarations in `(…)`]. Short form function with return types have to be wrapped in
(...)– this is way too lispy for 2018. Estetically this will be Zune territory when everybody these days expects iPods.
Although at some level I find using the actual word “where” in a function definition mildly exotic, it has a SQL feeling to it that’s… unnatural. Why wasn’t something less verbose chosen, like “<=”, “<-” or whatever combination.
This is not a critique, just user feedback – but at first glance, this choice of syntax seems far than ideal. And although maybe it shouldn’t, language aesthetics do matter, especially for early adoption. Defining functions is something that users will do all the time and a lot. As a consequence, reading functions will be done even more often. These changes make the syntax less readable.