Back in 2023 there was a discussion on discord to block the usage of certain built-in methods/functions. When I took over maintainership of Crystal more or less exactly a year ago did the leap exercise have a hard block on using the leap_year method. With hard block do I mean it erased that method from even being able to be used.
This discussion sparked me to refactor the method: Refactor leap year to use divisible_by? by meatball133 · Pull Request #13982 · crystal-lang/crystal (github.com). But I have also considered it for a while and decided it may be best to open the issue to the wider community if this block should still be in place or not, I will leave a pool below where you can vote on the issue. In the case that the block is voted to be removed then it will be merged in with the new update coming in around 1-2 weeks:
I voted for “leave it as it is”, why should I be the only one who suffer?
I hope crystal got featured a lot for this year challenge, seeing your effort on the track make me want to pick it to learn next for this year.
Thank you and more content is to come, although I am aiming to have a bigger focus on improving the tooling in general, been working on making the majority of the bash scripts available in Powershell as well to make it possible to develop in windows as well.
Do other tracks have a built-in way for checking if a year is a leap year? I think perhaps the exercise instructions could be updated upstream to warn that one shouldn’t use a built-in for this. For example, Strain includes the following text:
Keep your hands off that filter/reject/whatchamacallit functionality provided by your standard library! Solve this one yourself using other basic tools instead
If this situation doesn’t apply to other tracks, I’d still prefer to see an instructions append alerting me ahead of time that this track won’t allow me to use the leap_year? built-in. As a student, I’d be frustrated if I submit a working solution but it got rejected for a restriction that wasn’t clearly indicated in the instructions or the contents of the test suite.
Tone doesn’t carry over well in text, but this is an exercise marked easy so I’m not sure it’s productive to call this approach too easy. After all, it’s not a given that a language would have this built-in so the student likely had to look up the documentation.
The title of this discussion is "Crystal… ", so I presumed this would be an append type thing, and specifically changed for this track. While Ruby also has a leap? method (unsurprising, given the relationship between Crystal language and Ruby), I think it is not something that we can do across all tracks.
I remember at least talking about blocking in Ruby for a similar method call.
In 2014, we went so far as to overwrite the library methods for leap, to redirect them back to the student solution.
Yeah, this specific situation might not arise in other tracks, but simply the student should have some warning ahead of time that there’s a restriction on using built-ins. Blocking this method is essentially an additional track-specific test since they can’t pass if they use it. The stated purpose of an instructions append is as follows:
In some (rare) cases, you might want to expand on the exercise’s instructions.md file, for example when the exercise has implemented tests that are not covered by the existing instructions.
So an append is warranted in my opinion to document this extra track-specific test.
