1. 3

  2. 1

    I’m not really sure what a practical use case for this would be. What code would you spec like this? Or is it just a trick to be able to use the one-liner syntax?

    I tend to agree with @soulcutter: I think just not having a Cop for this is fine. Or have one that is disabled by default.

    1. 1

      Pretty sure there’s some confusion here. This discussion is about recommending against this syntax, not recommending to using it.

      Proponents of the syntax tend to say that it makes it possible to use the block matchers in combination with one-liner syntax, and that makes it possible to save some keystrokes on writing expect { subject }. I’m not sold on this though.

    2. 1

      I don’t see this as something rubocop needs to have any opinion about whatsoever. It’s legal ruby if you want to use it. Personally I’m not a huge fan of any one-liner RSpec syntax, but I wouldn’t force that opinion on others. My vote would be not to have any cop for this.

      I am a past RSpec core team contributor.

      1. 2

        Agree that it’s a valid Ruby syntax, but it’s not something that RSpec was designed to work with as per Jon Rowe and Myron Marston.

        RSpec::Expectations::Syntax via RSpec::Expectations::ExpectationTarget doesn’t make a clear distinction between BlockExpectationTarget and non-block ExpectationTarget, and mistakenly takes a lambda for a value, is passing it as a target to block matchers that call a .call method on it.

        That makes me think of this as a hack and a shortcoming of RSpec that may eventually be deprecated or becomes impossible.

        1. 1

          If you’re dead-set on protecting people from a possible future because it’s not intended behavior, go ahead. Consider that it’s also possible that it becomes supported despite the thinking in 2015, though, and then you’ll have been steering people away from it. (shrug) I mildly feel as though there being a distinction between BlockExpectationTarget and ExpectationTarget was a (well-intended) mistake. In my mind its meant to provide guidance, and if it misses the mark there it doesn’t mean it’s working incorrectly, it’s just a missed opportunity.

          Feels to me like you’ve made up your mind. This won’t affect me, but my opinion has been registered.

          1. 1

            I’m definitely inclined toward recommending against this syntax, but I also see that you have completely valid points.