Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule proposal: no-constructor-return #12481

Closed
golopot opened this issue Oct 23, 2019 · 6 comments · May be fixed by rsumner868/librealsense2.1#1, rsumner868/librealsense#4, O330oei/node#4 or O330oei/node#11
Closed

Comments

@golopot
Copy link
Contributor

@golopot golopot commented Oct 23, 2019

Please describe what the rule should do:

Forbid return statements in constructors.

What category of rule is this? (place an "X" next to just one item)

[x] Suggests an alternate way of doing something (suggestion)

Provide 2-3 code examples that this rule will warn about:

class Foo {
  constructor () {
    return Math;
  }
}

class Goo {
  constructor () {
    return this;
  }
}

Why should this rule be included in ESLint (instead of a plugin)?

In Javascript return value in constructor is allowed, and the return value is the evaluated value when the class is new-ed. A class created with pattern behaves very differently from a normal class in the OOP paradigm, for example, in that every new instance should be a separate object. There seemed to be no practical usage of this pattern. Forbidding this pattern prevents mistake resulting from unfamiliarity with the language or copy-paste error.

Are you willing to submit a pull request to implement this rule?

Possibly.

@kaicataldo
Copy link
Member

@kaicataldo kaicataldo commented Oct 24, 2019

I support this proposal.

@g-plane
Copy link
Member

@g-plane g-plane commented Oct 25, 2019

@kaicataldo Will you champion this? If so, it'll be better that remove your 👍.

@platinumazure
Copy link
Member

@platinumazure platinumazure commented Oct 25, 2019

I've added 👍 so any of us can champion and this is accepted.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Oct 25, 2019

Would it be valuable to add an option, so that any named non-arrow non-generator non-async function also was warned by this rule? (it'd probably want to ignore any return new in that case)

@g-plane g-plane self-assigned this Nov 5, 2019
g-plane added a commit that referenced this issue Nov 5, 2019
@g-plane g-plane added accepted and removed evaluating labels Nov 5, 2019
@kaicataldo
Copy link
Member

@kaicataldo kaicataldo commented Nov 6, 2019

@ljharb Seems like a good idea to also check non-class (is there a better term for that? Prototypal?) constructor functions, though I would advocate for adding that in later since we already have a PR.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Nov 6, 2019

ah, didn't realize #12529 existed.

I'd call them legacy constructors.

@eslint eslint bot locked and limited conversation to collaborators May 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.