Should no-wrap-func allow this exception?

[mightyiam]

I have some testing code that goes like

describe('thing', function () {
  it('throws', function () {
    (function () {thing()}).should.throw
  }
}) 

The no-wrap-func trips on that. But the parentheses are that for a good reason—otherwise it would have been a function statement without a name—which is an error.

Is there a neater way to write this?

Should no-wrap-func recognize this pattern?

[bathos]

A neater way might be to assign the function first, then use the reference -- depending on your preference. If I understand right, no-wrap-func is for those who feel parentheses as a means to expression-ize a function is bad for readability, with exception made for one very common pattern. So it looks like it's working right to me, unless no-wrap-func is actually supposed to just disallow expressionization that's not "used."

[mightyiam]

@bathos the "one very common pattern" would be

(function () {})()

where it is immediately called, and thus an IIFE?

If the former, then I'll write my code different.

Does anyone think that it is the latter? Well, it obviously isn't the latter.

Another rule for that could be no-unused-wrap-func.

[nzakas]

Yeah, this should be an exception.

[mightyiam]

Thank you @bathos and @nzakas.

[michaelficarra]

Why should this be an exception? If you don't want to wrap function expressions in unnecessary parentheses, prefix it with !.

describe('thing', function () {
  it('throws', function () {
    !function () {thing()}.should.throw
  }
}) 

[bathos]

@mightyiam yes, IIFE is what I meant. I had assumed this rule exception existed only because of its frequency and peculiar nature (i.e., you would not want to assign an IIFE if the whole point of it is to avoid outer scope pollution). But it seems that assumption was not correct -- based on nzakas response it seems the rule was only meant to disallow parenthetical function expressions when the parentheses aren't serving a purpose, whatever it may be.

@michaelficarra Since it seems the purpose of the rule is only to avoid pointless expressionization, I think the fact that there are other ways to trigger evaluation as an expression isn't significant. I (subjectively, I'll emphasize) consider using the negation operator here to be misleading; parens say "I contain an expression," which is exactly what we want to communicate, while ! says "I am the boolean inverse of the truthiness of the following expression" -- and then we do nothing with the value we've created, since we didn't really "mean" it.

[michaelficarra]

@bathos: You're already using an expression for its side effects. Seeing a ! or void in leading statement position indicates that to me more clearly. But of course, it is subjective as you say.

Why don't you turn off the rule? Is this not exactly the kind of thing this rule is meant to detect?

[bathos]

That's fair, @michaelficarra. Everyone has their own take on what conveys intention clearly in code. You mentioned void -- that's actually the perfect choice in my eyes. I'd never thought of it before, I guess because it's over in the heap of unloved toys we're not supposed to want to touch :)

I'm not the OP, btw -- not sure if that last line was meant for me; I actually don't have this rule on, at least not on my current project. But the docs at http://eslint.org/docs/rules/no-wrap-func do make it sound like this is "exactly the kind of thing this rule is meant to detect," as you said. So if the OP's example becomes valid with no-wrap-func, I think the docs will need to change too.

[michaelficarra]

Sorry @bathos, I meant that second paragraph for @mightyiam.

[nzakas]

The purpose of this rule is to say "removing the parentheses doesn't change the meaning". However, in this case, removing the parentheses definitely does change the meaning unless you add something like void or !. So, I still feel like this is a valid exception to this rule.

[nzakas]

Working on this.

[mightyiam]

Thank you @nzakas and everyone on the discussion.

@nzakas I hope you figure out the rest of the issues from c11c408.