Crystal: RFC: curly braces instead of end

Created on 13 Aug 2020  路  2Comments  路  Source: crystal-lang/crystal

Problem

  • Most text editors autocomplete { with } and automatically insert indentation after you hit enter, but few editors autocomplete def x(...) with end, which makes programming languages that use end much harder to write. In fact, it's much harder for the editor to complete with end since there are a variety of situations in which end should be inserted (class definitions, method/function definitions, blocks), but only one situation where a close bracket should be inserted (after an open bracket).
  • It's more succinct. {} is two characters whereas end is three.
  • Curly braces are more popular so people are likely to know about them.
  • Using curly brackets would get rid of two magic keywords (do and end) and thus would simplify the syntax so it is easier to read. It also frees you up to use do and end as variables.

Proposal

This would apply to blocks, function/method definitions, and class definitions.

Instead of this:

class Example
  def self.hello
    3.times do
      puts "Hello, World!"
    end
  end
end

It would be this:

class Example {
  def self.hello {
    3.times {
      puts "Hello, World!"
    }
  }
}

This would be a major breaking change but backwards compatibility measures can be taken (supporting both curly braces and end, for example). And Crystal isn't 1.0 yet so backwards compatibility shouldn't be that big of a deal.

The idea is mentioned by @j8r here: https://github.com/crystal-lang/crystal/issues/9080#issuecomment-641563245

I know this might be an unwelcome proposal but please do consider developing a unique syntax based on developer ergonomics instead of doing whatever Ruby does (Ruby is great in a lot of ways but IMO end is one of its weak points).

Most helpful comment

His idea was related to that PR, allowing 1 line methods. I don't think the intent was to suggest replacing end with {} across the board.

Given this would be a massive breaking change right before 1.0.0, I doubt it'll ever happen.

Also for whatever it's worth, using {} for blocks is also valid. I.e. your two 3.times examples are equivalent, although do ... end is the more idiomatic way if there is more than 1 line of code in the block.

Personally I find it uglier, given you didn't have to include that initial {. Also I imagine this syntax would conflict with the {} block syntax in some ways...

All 2 comments

His idea was related to that PR, allowing 1 line methods. I don't think the intent was to suggest replacing end with {} across the board.

Given this would be a massive breaking change right before 1.0.0, I doubt it'll ever happen.

Also for whatever it's worth, using {} for blocks is also valid. I.e. your two 3.times examples are equivalent, although do ... end is the more idiomatic way if there is more than 1 line of code in the block.

Personally I find it uglier, given you didn't have to include that initial {. Also I imagine this syntax would conflict with the {} block syntax in some ways...

This has been proposed and discussed multiple times in the past. We will not do this.

Was this page helpful?
0 / 5 - 0 ratings