Make fn built-in in strict-mode

[NullVoxPopuli]

Propose making (fn) a built in helper

Rendered

Summary

Today, we need

import { fn } from '@ember/helper'`;

This should be built in, and not require an import.

---

---

An FCP is required before merging this PR to advance to Accepted.

Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.

Exploring Stage Description

This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.

An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.

An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.

Accepted Stage Description

To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.

If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.

When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.

Checklist to move to Exploring

• The team believes the concepts described in the RFC should be pursued.
• The label S-Proposed is removed from the PR and the label S-Exploring is added.
• The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

• This PR has had the Final Comment Period label has been added to start the FCP
• The RFC is announced in #news-and-announcements in the Ember Discord.
• The RFC has complete prose, is well-specified and ready for implementation.
  • All sections of the RFC are filled out.
  • Any unanswered questions are outlined and expected to be answered before Ready for Release.
  • "How we teach this?" is sufficiently filled out.
• The RFC has a champion within one of the relevant teams.
• The RFC has consensus after the FCP period.

[les2]

contrary point of view: if the code editor will be able to suggest the import for fn automatically then maybe implicit import isn't needed.

that said, it does seem useful to have a prologue (like java.lang.* in Java and similar things in other languages) that users can locally override via imports as desired.

👍🏿 from me

[SolPier]

I also 👍 the proposed alternative of a prolog of some kind, and if not no changes at all:

Coming from a ruby background I find 'magic' (implicit and untrackable injections of any object) exhausting, especially while debugging.

Not loving magic anymore meant JS imports where a blessing to me.
And it seemed ember was going in this direction too, with the explicit imports of ember-template-imports for helpers, modifiers, components, potentially other filetypes ( ❤️ ).
Long gone where the days of debating the best conventions for filenames and locations/structure that we had during the 'Module Unification' #143, which aimed to make the implicit loading of local components work.

Not that to a user it has negative value (sugar feels good), but that would be an overhead to smo who wants to learn ember. Or to a rare ember user debugging / accessing a side project.
The more vanilla and 'free of surprises' ember main files are, the better it is for its adoption in my opinion.

A prologue would be a good compromise.

[NullVoxPopuli]

A prologue would be a good compromise.

anyone can more or less do this themselves in userspace via this technique: #946 (comment)

especially while debugging.

has anyone ever needed to debug inside fn? if an abstraction has good error messages and in general isn't "leaky" - what's it matter if a feature is provided by the language vs developed in user space? we should optimize for convenience in this scenario.

We don't want to have folks importing if, each, each-in, let, <div>, <html> etc, otherwise... why have any language at all?

[SolPier]

Very good points, I see it clearer now, and you are right.

That means we have 2 kinds of helpers, those who are 'pre-loaded' and those who need an import from the user.
And what routes this or that helper to one list is their usage frequency.
if, each and each-in meets that threeshold from now, and I'm not sure let should.

It could be beneficial to have an explicit note / list / remarks about that in the documentation ?
Just so it is known that not all helpers are used the same way (some require import, others don't).

But that's out of this PR scope.

[achambers]

Makes sense to me.

[achambers]

RFC Review (1) are in favour of this.

[kategengler]

We decided to move this RFC along with #997, #999, #1000 into FCP to accepted today at the RFC meeting.

[SolPier]

(small typo)