Consider renaming be_true and be_false to be_truthy and be_falsey

[myronmarston]

I've heard some grumbling about this recently, and I've always found it a bit puzzling as well. be_true and be_false really act like be_truthy and be_falsey but aren't named as such. I think lots of folks think be_true passes if and only if the value is true, and be_false passes if and only if the value is false but that's not the case. You can already do be true and be false (no underscore) for the exact match, so I don't think there's any need to change the semantics of be_true and be_false -- instead, I'd like to deprecate them, in favor of be_truthy and be_falsey, which are more accurately named. Thoughts?

[fables-tales]

👍 I could implement this tomorrow if we're there right now, or do you want to get some community feedback first?

[cupakromer]

👍

[alindeman]

I think this is a good idea.

[JonRowe]

@samphippen's PR's LGTM, but I'm not really in favour of this change, I've never liked 'Truthy' or 'Falsey' as terms so I kind of feel it's a backwards step in terms of language for some extra pedantry... I've always used be_true meaning "to be truthy" and from my observation it's always been the ruby way to treat the two interchangeably.

That said I'd have nothing against adding be_truthy as well as be_true. I've always been more specific when I want actually true.

[soulcutter]

I agree with @JonRowe - truthy/falsey are unlikely to be expected to exist, where be_true / be_false are expected to exist. I also feel that the whole true vs truthy thing is a rubyism, and rubyists expect true and false to mean "evaluate as true" or "evaluate as false".

I also know that this change will affect a LOT of people. Is it adding enough value to make it worth it? I don't think so.

[soulcutter]

I'm on the fence. I realized there is some parity with Jasmine having truthy/falsey (they call it falsy btw). Maybe it makes sense to continue to support it with warnings for a while (until rspec 4 even?). Or indefinitely?

[myronmarston]

I agree with @JonRowe - truthy/falsey are unlikely to be expected to exist, where be_true / be_false are expected to exist. I also feel that the whole true vs truthy thing is a rubyism, and rubyists expect true and false to mean "evaluate as true" or "evaluate as false".

Maybe I'm an exception, but I think of non-nil, non-false objects as "being treated as true", but I don't think of them as "being true". I think it's also quite confusing that the semantics and meaning of be true and be_true are different (and likewise, be_false and be false are different). I've heard a bit of grumbling in the community about this as well; here's one example.

All that said, maybe we should invite community discussion on this? I can mention and link to this from the rspec 3 blog post that'll be going live next week if you like.

[myronmarston]

That said I'd have nothing against adding be_truthy as well as be_true. I've always been more specific when I want actually true.

@JonRowe -- if we move this direction, I'd definitely want be_true removed (sans some deprecation period, which may just be 2.99). I think the difference between be true and be_true is confusing, given that they read aloud exactly the same, and that an underscore is really just a stand-in for a space in a code identifier.

[alindeman]

Maybe I'm an exception, but I think of non-nil, non-false objects as "being treated as true", but I don't think of them as "being true". I think it's also quite confusing that the semantics and meaning of be true and be_true are different (and likewise, be_false and be false are different). I've heard a bit of grumbling in the community about this as well; here's one example.

I agree. It definitely confused me at first. Given Ruby is a strongly typed language, be_true feels like it should mean == true (and that's what you get with be true).

All that said, maybe we should invite community discussion on this? I can mention and link to this from the rspec 3 blog post that'll be going live next week if you like.

I'm a little concerned about community discussion here because I'm not sure what other rationale could be brought up at this point other than personal preferences and personal ways of internalizing true/false in Ruby. We might cause a lot of useless noise over it? But I might be thinking too hard.

[soulcutter]

Well, I don't disagree with @myronmarston 's points, I guess it's positive to remove the ambiguity between be_true / be true.

[myronmarston]

BTW, I don't have a strong opinion on be_falsy vs be_falsey. falsey seems to be the more common term based on number of google results, though:

[alindeman]

Given that there are some results for both, maybe we alias them?

[soulcutter]

In fairness I believe Falsey gets used as a surname, so there's that...

[fables-tales]

Injecting opinions:

I agree with @alindeman, I don't think we need to do a community consult here (for the reasons he listed). I do think we should alias falsey and falsy. I do think we should remove be_true and be_false with deprecation period in 2-99 (otherwise we're obliged to keep them until 4).

[JonRowe]

An alternative way of removing confusion would be to make be true behave like be_true does now, and encourage people to use eq true when they actually want a direct comparison.

Although if we do go with this my 2¢ is that I'd favour falsey over falsy because falsey is the same number of chars as truthy and I like the parity ;)

[myronmarston]

An alternative way of removing confusion would be to make be true behave like be_true does now, and encourage people to use eq true when they actually want a direct comparison.

I think this would increase confusion. The be matcher has well known and documented semantics that state that be x is precisely the same as equal?(x). Special casing it for one value would create tons of confusion. It would get worse when you are dealing with a variable (e.g. expect(x).to be y -- suddenly the value of y would determine how the matcher operates; if it's true it would act one way and if it's a normal ruby object it would act another way.

I like the idea of aliasing be_falsey and be_falsy so that either can be used.

[myronmarston]

This has been addressed.