Converting stabby lambda to lambda keyword results in ArgumentError

Metadata

• Ruby version: ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-darwin18]
• @prettier/plugin-ruby version: 0.12.0

Input

class ReadingResource < ApplicationResource
  filter :complete, apply: ->(records, value, _options) {
    if value == ['true']
      records.where('readings.completed_at IS NOT NULL')
    else
      records.where('readings.completed_at IS NULL')
    end
  }
end

Current output

class ReadingResource < ApplicationResource
  filter :complete, apply: lambda do |records, value, _options|
    if value == %w[true]
      records.where('readings.completed_at IS NOT NULL')
    else
      records.where('readings.completed_at IS NULL')
    end
  end
end

This output results in an error when executing:

ArgumentError:
  tried to create Proc object without a block

I’m not quite sure why this is happening; it sounds like a difference of precedence between the lambda keyword and stabby lambdas, like the block is being passed to #filter instead of to lambda. But I can’t find documentation on a precedence difference.

In case it helps, if I provide parents for #filter the error is fixed:

class ReadingResource < ApplicationResource
  filter(
    :complete,
    apply:
      lambda do |records, value, _options|
        if value == %w[true]
          records.where('readings.completed_at IS NOT NULL')
        else
          records.where('readings.completed_at IS NULL')
        end
      end,
  )
end

Expected output

I don’t have a preference between the lambda keyword and stabby lambdas, but if there’s a syntactic reason the lambda keyword can’t be used here then I think it’d be best to keep the stabby lambda:

class ReadingResource < ApplicationResource
  filter :complete, apply: ->(records, value, _options) {
    if value == ['true']
      records.where('readings.completed_at IS NOT NULL')
    else
      records.where('readings.completed_at IS NULL')
    end
  }
end

[kddnewton]

Ehh wasn’t so hard. Going to merge the fix, will be part of the next release.

[kddnewton]

Yeah the problem here is operator precedence. The lambda should be using {} (which has higher precedence) versus do...end. I don’t think I’ve seen the case where it’s a multi-line breaking lambda as a hash value, which is probably the problem.