I really like this exercise; it was a nice challenge to implement a tail-recursive solution. However, there might be a small problem with the tests. The function should take a list as an argument and return a list; there is even a typespec @spec flatten(list) :: list . However, there is no test that checks that a list is passed as an argument. I’ve seen community solutions where recursive calls are made with arguments that are not lists. Any thoughts on this?
Hi! I’m answering as an Elixir maintainer here, but maybe somebody else will want to answer from another perspective.
The Elixir track follows the platform-wide problem specifications for practice exercises as exactly as possible, unless there is an Elixir-specific reason to change something.
The authors of this exercise didn’t include any kind of input validations in the problem specifications so the Elixir implementation of the exercise doesn’t have them either. I would guess that means this exercise wasn’t meant to practice input validations.
1 Like
I see. I guess this is different from learning exercises which are language specific?
Yep. That’s correct!
To add to this, exercises have a tendency towards complexity, as people want to add things to test different elements (input validation, edge cases, etc). The problem with this is that you end up having to put a lot of energy into things that are not focussed on your practicing the core of the exercise. Once you’ve solved 10 exercises with input validation, it’s just a PITA on the next 100 exercises. So we tend to not have tests for production-style software-development practice (e.g. input validation) but instead focus the tests only on the problem at hand.
2 Likes
If I recall correctly, we’ve actually removed input validation from some exercises for this exact reason. There are some exercises that are explicitly about input validation. There are a whole lot of others that can focus on other problems.