FAQ

Why isn't the language indentation based?

Apart from the "Crystal has Ruby-inspired syntax" reason, there are more reasons:

1. If you copy and paste a snippet of code, you have to manually re-indent the code for it to work. This slows you down if you just wanted to do a quick test.
2. If you want to comment some code, for example comment an if condition, you have to re-indent its body. Later you want to uncomment the if and you'll need to re-indent the body. This slows you down and it's cumbersome.
3. Macros become harder to write. Consider the json_mapping macro. It defines defs, uses case ... when ... else ... end without having to bother whether the generated code will be indented. Without end, the user would have to correctly indent the lines that would be generated.
4. If you want a template language like ERB or ECR for a language that doesn't care about whitespace, you'll have to put those end to signal where conditions/loops/blocks end.
5. Right now you can do: [1, 2, 3].select { |x| x.even? }.map { |x| x.to_s }. Or you can do it with do .. end. How would you chain calls in an indentation-based language? Usage of { ... } is not valid, only indentation should be used to match code blocks.
6. Assuming one day we have a REPL, in which you tend to write code quickly, it's tedious and bug-prone to match indentation, because whitespace is basically invisible.

Because of all the above reasons, know that the end keyword is here forever: there's no point in trying to suggest changing the language to an indentation-based one.

Why don't you add syntax for XYZ?

Before suggesting syntax additions, ask this question:

• Can it be currently done with the current syntax?

If the answer is "yes", there's probably no need to add new syntax for something that can be already done. Adding syntax means we have to be sure it doesn't conflict with the existing syntax. all users will have to learn something new, and it needs to be documented.

Maybe the current syntax is long to write or involves a couple of composed methods, but we should favor method composition instead of specific rules for specific problems.