From 57c174c3bc8bbf162bdf958f1eb65b80325f1808 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 22 Dec 2023 14:02:13 -0500
Subject: [PATCH 1/8] Make fn built in

---
 text/0000-make-fn-built-in.md | 84 +++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 text/0000-make-fn-built-in.md

diff --git a/text/0000-make-fn-built-in.md b/text/0000-make-fn-built-in.md
new file mode 100644
index 0000000000..73e1cf60f1
--- /dev/null
+++ b/text/0000-make-fn-built-in.md
@@ -0,0 +1,84 @@
+---
+stage: accepted
+start-date: # In format YYYY-MM-DDT00:00:00.000Z
+release-date: # In format YYYY-MM-DDT00:00:00.000Z
+release-versions:
+teams: # delete teams that aren't relevant
+  - cli
+  - data
+  - framework
+  - learning
+  - steering
+  - typescript
+prs:
+  accepted: # Fill this in with the URL for the Proposal RFC PR
+project-link:
+suite: 
+---
+
+<!--- 
+Directions for above: 
+
+stage: Leave as is
+start-date: Fill in with today's date, 2032-12-01T00:00:00.000Z
+release-date: Leave as is
+release-versions: Leave as is
+teams: Include only the [team(s)](README.md#relevant-teams) for which this RFC applies
+prs:
+  accepted: Fill this in with the URL for the Proposal RFC PR
+project-link: Leave as is
+suite: Leave as is
+-->
+
+# <RFC title>
+
+## Summary
+
+> One paragraph explanation of the feature.
+
+## Motivation
+
+> Why are we doing this? What use cases does it support? What is the expected
+outcome?
+
+## Detailed design
+
+> This is the bulk of the RFC.
+
+> Explain the design in enough detail for somebody
+familiar with the framework to understand, and for somebody familiar with the
+implementation to implement. This should get into specifics and corner-cases,
+and include examples of how the feature is used. Any new terminology should be
+defined here.
+
+## How we teach this
+
+> What names and terminology work best for these concepts and why? How is this
+idea best presented? As a continuation of existing Ember patterns, or as a
+wholly new one?
+
+> Would the acceptance of this proposal mean the Ember guides must be
+re-organized or altered? Does it change how Ember is taught to new users
+at any level?
+
+> How should this feature be introduced and taught to existing Ember
+users?
+
+## Drawbacks
+
+> Why should we *not* do this? Please consider the impact on teaching Ember,
+on the integration of this feature with other existing and planned features,
+on the impact of the API churn on existing apps, etc.
+
+> There are tradeoffs to choosing any path, please attempt to identify them here.
+
+## Alternatives
+
+> What other designs have been considered? What is the impact of not doing this?
+
+> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
+
+## Unresolved questions
+
+> Optional, but suggested for first drafts. What parts of the design are still
+TBD?

From 575f5ee3f149e40e5f28d76b90931f5fa2560cea Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 22 Dec 2023 15:16:23 -0500
Subject: [PATCH 2/8] Write

---
 text/0000-make-fn-built-in.md | 86 +++++++++++++++++++++--------------
 1 file changed, 51 insertions(+), 35 deletions(-)

diff --git a/text/0000-make-fn-built-in.md b/text/0000-make-fn-built-in.md
index 73e1cf60f1..e51fa6a2ca 100644
--- a/text/0000-make-fn-built-in.md
+++ b/text/0000-make-fn-built-in.md
@@ -1,17 +1,14 @@
 ---
 stage: accepted
-start-date: # In format YYYY-MM-DDT00:00:00.000Z
+start-date: 2023-12-22T00:00:00.000Z
 release-date: # In format YYYY-MM-DDT00:00:00.000Z
 release-versions:
 teams: # delete teams that aren't relevant
-  - cli
-  - data
   - framework
   - learning
-  - steering
   - typescript
 prs:
-  accepted: # Fill this in with the URL for the Proposal RFC PR
+  accepted: https://github.com/emberjs/rfcs/pull/998
 project-link:
 suite: 
 ---
@@ -30,55 +27,74 @@ project-link: Leave as is
 suite: Leave as is
 -->
 
-# <RFC title>
+# Make `(fn)` a built in helper 
 
 ## Summary
 
-> One paragraph explanation of the feature.
+Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `(fn)` modifier.
+Because event listening is so commonplace, this is a grating annoyance for developers.
+
+This RFC proposes that `(fn)` be built in to `glimmer-vm` and not require importing.
 
 ## Motivation
 
-> Why are we doing this? What use cases does it support? What is the expected
-outcome?
+There is precedence for `fn` being built in, as all the other partialy-application utilities are already built in.
 
-## Detailed design
+- `(helper)`
+- `(modifier)`
+- `(component)`
 
-> This is the bulk of the RFC.
+It's historically been the stance that, 
 
-> Explain the design in enough detail for somebody
-familiar with the framework to understand, and for somebody familiar with the
-implementation to implement. This should get into specifics and corner-cases,
-and include examples of how the feature is used. Any new terminology should be
-defined here.
+"If it can be built in userspace, it should be, leaving the framework-y things to be only what can't exist in userspace"
 
-## How we teach this
+But to achieve the ergonomics that our users want, we should provide a more cohesive experience, rather than require folks import from all of (in the same file):
+- `@glimmer/component`
+- `@glimmer/tracking`
+- `@ember/modifier`
+- `@ember/helper`
+- `ember-modifier`
+- `ember-resources`
+- `tracked-built-ins`
 
-> What names and terminology work best for these concepts and why? How is this
-idea best presented? As a continuation of existing Ember patterns, or as a
-wholly new one?
+Some of the above may unify in a separate RFC, but for the template-utilities, since the modules that provide them are already so small, it makes sense to inherently provide them by default. Especially as we can target strict-mode only, so that we don't run in to the same implementation struggles that built-in [Logical Operators](https://github.com/emberjs/rfcs/pull/562), [Numeric Comparison Operators](https://github.com/emberjs/rfcs/pull/561), and [Equality Operators](https://github.com/emberjs/rfcs/pull/560) have faced.
 
-> Would the acceptance of this proposal mean the Ember guides must be
-re-organized or altered? Does it change how Ember is taught to new users
-at any level?
+<details><summary>some context on those RFCs</summary>
 
-> How should this feature be introduced and taught to existing Ember
-users?
+The main problem with adding default utilities without strict-mode is that it becomes very hard to implement a way for an app to incrementally, and possibly per-addon, or per-file, to adopt the default thing due to how resolution works. Every usage of the built in utility would also require a global resolution lookup (the default behavior in loose mode templates) to see if an addon is overriding the built ins -- and then, how do you opt in to the built ins, and _not_ let addons override what you want to use?
 
-## Drawbacks
+With gjs/gts/`<template>`, this is much simpler, as in strict-mode, you can check if the scope object defines the helpers, and if not, use the built in ones.
 
-> Why should we *not* do this? Please consider the impact on teaching Ember,
-on the integration of this feature with other existing and planned features,
-on the impact of the API churn on existing apps, etc.
+This strategy of always allowing local scope to override default-provided utilities will be a recurring theme.
 
-> There are tradeoffs to choosing any path, please attempt to identify them here.
+</details>
 
-## Alternatives
+---------------
+
+_Making `fn` a built-in will help make writing components feel more cohesive and well supported, as folks will not need to cobble together many imported values_
+
+----------------
+
+
+## Detailed design
 
-> What other designs have been considered? What is the impact of not doing this?
+This change would affect strict-mode only. This is so that today's existing code that imports `fn` from `@ember/helper` will still work due to how values define locally in scope override globals.
+
+The behavior of `fn` would be the same as it is today, but defined by default in the `glimmer-vm`.
+
+## How we teach this
+
+Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `fn` by the time this would be implemented, would only remove the import.
+
+## Drawbacks
+
+People may not know where `fn` is defined.
+- counterpoint: do they need to?
+
+## Alternatives
 
-> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
+n/a
 
 ## Unresolved questions
 
-> Optional, but suggested for first drafts. What parts of the design are still
-TBD?
+n/a

From ef803c7eeef0e7c4c8ad34fda5c5e40dd97602d2 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 22 Dec 2023 15:23:14 -0500
Subject: [PATCH 3/8] Update 0000-make-fn-built-in.md

---
 text/0000-make-fn-built-in.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-make-fn-built-in.md b/text/0000-make-fn-built-in.md
index e51fa6a2ca..312575c0f6 100644
--- a/text/0000-make-fn-built-in.md
+++ b/text/0000-make-fn-built-in.md
@@ -32,7 +32,7 @@ suite: Leave as is
 ## Summary
 
 Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `(fn)` modifier.
-Because event listening is so commonplace, this is a grating annoyance for developers.
+Because partial application is so commonplace, this is a grating annoyance for developers.
 
 This RFC proposes that `(fn)` be built in to `glimmer-vm` and not require importing.
 

From c012e50b303e8fa508b863bb4612b0756d3d33b9 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 22 Dec 2023 15:23:35 -0500
Subject: [PATCH 4/8] Rename 0000-make-fn-built-in.md to
 0998-make-fn-built-in.md

---
 text/{0000-make-fn-built-in.md => 0998-make-fn-built-in.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename text/{0000-make-fn-built-in.md => 0998-make-fn-built-in.md} (100%)

diff --git a/text/0000-make-fn-built-in.md b/text/0998-make-fn-built-in.md
similarity index 100%
rename from text/0000-make-fn-built-in.md
rename to text/0998-make-fn-built-in.md

From 828ffabbb6a72abcccdb809951de6220b4cb9ca2 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Sat, 23 Dec 2023 17:19:06 -0500
Subject: [PATCH 5/8] Update text/0998-make-fn-built-in.md

Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
---
 text/0998-make-fn-built-in.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0998-make-fn-built-in.md b/text/0998-make-fn-built-in.md
index 312575c0f6..737ab6f5b0 100644
--- a/text/0998-make-fn-built-in.md
+++ b/text/0998-make-fn-built-in.md
@@ -31,7 +31,7 @@ suite: Leave as is
 
 ## Summary
 
-Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `(fn)` modifier.
+Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `(fn)` helper.
 Because partial application is so commonplace, this is a grating annoyance for developers.
 
 This RFC proposes that `(fn)` be built in to `glimmer-vm` and not require importing.

From 74b942f78e6c18caffa74cbc95ee1893daa2520b Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Sat, 23 Dec 2023 17:19:19 -0500
Subject: [PATCH 6/8] Update text/0998-make-fn-built-in.md

Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
---
 text/0998-make-fn-built-in.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0998-make-fn-built-in.md b/text/0998-make-fn-built-in.md
index 737ab6f5b0..99b6751d7c 100644
--- a/text/0998-make-fn-built-in.md
+++ b/text/0998-make-fn-built-in.md
@@ -78,7 +78,7 @@ _Making `fn` a built-in will help make writing components feel more cohesive and
 
 ## Detailed design
 
-This change would affect strict-mode only. This is so that today's existing code that imports `fn` from `@ember/helper` will still work due to how values define locally in scope override globals.
+This change would affect strict-mode only. This is so that today's existing code that imports `fn` from `@ember/helper` will still work due to how values defined locally in scope override globals.
 
 The behavior of `fn` would be the same as it is today, but defined by default in the `glimmer-vm`.
 

From 6775b37006811ab502392ae952043a3aa332b902 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 16 Feb 2024 15:31:32 -0500
Subject: [PATCH 7/8] Updates

---
 text/0998-make-fn-built-in.md | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/text/0998-make-fn-built-in.md b/text/0998-make-fn-built-in.md
index 99b6751d7c..04a9c1e670 100644
--- a/text/0998-make-fn-built-in.md
+++ b/text/0998-make-fn-built-in.md
@@ -82,6 +82,8 @@ This change would affect strict-mode only. This is so that today's existing code
 
 The behavior of `fn` would be the same as it is today, but defined by default in the `glimmer-vm`.
 
+`fn` will be a keyword, and for backwards compatibility, this will require that keywords, in strict mode, be overrideable by the strict-mode scope bag.
+
 ## How we teach this
 
 Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `fn` by the time this would be implemented, would only remove the import.
@@ -89,12 +91,14 @@ Once implemented, the guides, if they say anything about gjs/gts/`<template>` an
 ## Drawbacks
 
 People may not know where `fn` is defined.
-- counterpoint: do they need to?
+- counterpoint: do they need to?, we are defining a lanugage, trying to make it ergonomic.
 
 ## Alternatives
 
-n/a
+- Use a prelude
+    - preludes were mentioned during the initial exploration of strict-mode templates, and were decided against, because addons would not be able to assume a prelude exists, as apps could define their own, and this sort of re-introduces the app-tree-merging behavior that we've been trying to get away from. 
 
 ## Unresolved questions
 
-n/a
+- What happens if we want to remove a keyword? (like `mut`)
+  - same as today, we only need to commit to a major to remove the keyword in and then do it - providing ample deprecation time, ending with the final removal.

From 928306e1431f5576b37638af57677c56a52ff5f1 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 27 Mar 2024 12:10:41 -0400
Subject: [PATCH 8/8] Update text/0998-make-fn-built-in.md

Co-authored-by: Aaron Chambers <aaron.chambers@hey.com>
---
 text/0998-make-fn-built-in.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/text/0998-make-fn-built-in.md b/text/0998-make-fn-built-in.md
index 04a9c1e670..83c96dce4c 100644
--- a/text/0998-make-fn-built-in.md
+++ b/text/0998-make-fn-built-in.md
@@ -88,6 +88,8 @@ The behavior of `fn` would be the same as it is today, but defined by default in
 
 Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `fn` by the time this would be implemented, would only remove the import.
 
+The guides should also detail which functions are built in to the framework and, therefore, do not need to be imported.
+
 ## Drawbacks
 
 People may not know where `fn` is defined.