Feature request: relaxing fart functions limitations

[bunglegrind]

Is your feature request related to a problem? Please describe.

const fart1 = (v) => v.size.w > v.size.h;
const fart2 = ({size}) => size.w > size.h;
function fart3({size}) {
    return size.w > size.h;
}
const fart4 = ([size]) => size.w > size.h;
function fart5([size]) {
    return size.w > size.h;
}

export default Object.freeze({
    fart1,
    fart2,
    fart3,
    fart4,
    fart5
});

Regarding fart2 and fart4, JSLint raises a warning: "Use 'function (...)', not '(...) =>' when arrow functions become too complex." The biggest issue with fart functions is when curly brackets are used on the right side of the arrow, not on the left side. I propose to reconsider the two warnings above enabling fart functions together with destructuring assignments.

Describe the solution you'd like No warnings when (curly) brackets are used on the left side of arrow functions.

Describe alternatives you've considered No alternatives provided.

[bunglegrind]

I've just noticed this other issue: https://github.com/jslint-org/jslint/issues/382 (but mine is a feature request 😄 ) Anyway, I would like to add my considerations to the debate: the supposed lack of clarity of fart arrows + destructuring is not related to fart arrows at all, I mean, I don't think that ({bar}) => ... is more confusing than function foo({bar}) {...}

So, IMHO we should ask ourselves if destructuring assignement should be allowed in both the cases, not only in the arrow function one.

[bunglegrind]

Thanks for #414 !

However, I disagree about curly brackets on the right side....they're the main cause of arrow function ambiguity.

[kaizhu256]

• i'm generally anti-fat-arrow, whether toy-case, parameter-destructured, or with statement-blocks.

• if enough people want to use fat-arrows in certain ways,

  • jslint will let you to do so with directive /*jslint fart*/,
  • but its not going to nitpick how one bad use-case is worse than another.

[bunglegrind]

ok, fine. thanks.