From 7532d2a4471ee639a7830170c817662622086464 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Mon, 17 May 2021 09:41:40 -0400
Subject: [PATCH 1/8] Fill out Summary and Motivation sections

---
 text/0000-default-managers.md | 111 ++++++++++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)
 create mode 100644 text/0000-default-managers.md

diff --git a/text/0000-default-managers.md b/text/0000-default-managers.md
new file mode 100644
index 0000000000..b26d88ba6a
--- /dev/null
+++ b/text/0000-default-managers.md
@@ -0,0 +1,111 @@
+- Start Date: 2021-05-17
+- Relevant Team(s): Ember.js, Learning
+- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)
+- Tracking: (leave this empty)
+
+# Default Managers
+
+## Summary
+
+Anything that can be in a template has its lifecycle managed by the manager pattern.
+Today, we have known managers for `@glimmer/component`, `@ember/helper`, etc.
+But what happens when the VM encounters an object for which there is no manager?,
+such as a plain function? This RFC explores and proposes a default behavior for
+those unknown scenarios.
+
+## Motivation
+
+The addon, [ember-could-get-used-to-this](https://github.com/pzuraq/ember-could-get-used-to-this)
+demonstrated that it's possible to use plain functions for helpers and modifiers.
+And since Ember 3.25, helpers can be invoked directly from value references, this opened
+a whole new world of ergonomics improvements where a dev could define a function in a
+component class and use that function **as** a helper, thanks to
+ember-could-get-used-to-this implementing a Helper Manager that _knew what to do with plain functions.
+
+This has the impact of greatly reducing helper burden for apps and addon devs, in that,
+folks no longer need to jump over to the app/addon helpers directory to create a helper
+"just to do this one simple thing". It's all now `{{this.myHelper}}` or `{{this.myModifier}}`.
+
+This has the added benefit of, with template strict mode, using plain functions in module-scope
+for helpers and modifiers.
+
+For Example:
+
+<!--
+  If you're reading this RFC non-rendered, ignore the "jsx" language tag.
+  "jsx" is incorrect, and isn't perfect, but "gjs" syntax highlighting
+  hasn't been added to GitHub's highlighting yet.
+-->
+
+```jsx
+const double = num => num * 2;
+const resizable = element => { /* ... */ };
+
+<template>
+  {{double 2}}
+  <div {{resizable}}></div>
+</template>
+```
+_Note: `<template>` is experimental syntax, and should not be be the focus of this example_
+
+Another aspect of which is exciting is that it becomes easier, in tests to grab
+the output of yielding components:
+
+```jsx
+test('...', async function (assert) {
+  let output = [];
+  const capture = (...args) => output = args;
+
+  await render(hbs`
+    <MyComponent as |yielded info and things|>
+       {{capture yielded info and things}}
+    </MyComponent>
+  `);
+
+  assert.equal(output[0], /* value of yielded */ );
+  assert.equal(output[1], /* value of info */ );
+  // ...
+})
+```
+
+## 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 be89fb5d0d227f45339e2f7d7bbc7e660bea6ae9 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Mon, 21 Jun 2021 21:15:15 -0400
Subject: [PATCH 2/8] Fill out everything but the 'How we teach this' section

---
 text/0000-default-managers.md | 254 ++++++++++++++++++++++++++++++++--
 1 file changed, 241 insertions(+), 13 deletions(-)

diff --git a/text/0000-default-managers.md b/text/0000-default-managers.md
index b26d88ba6a..cb1491b07c 100644
--- a/text/0000-default-managers.md
+++ b/text/0000-default-managers.md
@@ -70,13 +70,229 @@ test('...', async function (assert) {
 
 ## Detailed design
 
-> This is the bulk of the RFC.
+Each implemented meta-manager needs a default manager specified. The logic for choosing when to use
+a default manager is, at a high-level:
+
+```
+if (noExistingManagerFor(X)) {
+  return defaultManager;
+}
+```
+Where X is one of a Helper, Modifier, or Component
+
+### Helpers
+
+Borrowing most of the implementation from ember-could-get-used-to-this with one change: the signature
+of the function may receive an options-like object as the last parameter if named arguments are specified.
+This aligns with the _syntax_ of helper invocation where named arguments may not appear before the last
+positional argument.
+
+#### Example with mixed params
+
+```hbs
+{{this.calculate 1 2 op="add"}}
+```
+would be an example invocation of a function with the following signature
+expressed as TypeScript for clarity:
+```ts
+type Options = { op: 'add' | 'subtract' }
+class A {
+  calculate(first: number, second: number, options: Options) {
+    // ...
+  }
+}
+```
+for unknown amounts of parameters, the [typescript can be awkward](https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgMJwDYIK4bpAeQAcxgB7EAZ2QG8AoZR5MogLmQHI4ATbj5AD6dK2AEYcA3HQC+dMAE8iKdFlz4IAQSgBzagF5kAbQB0pkNgC2o6IYC6AGjSYceQiXJVbUujGwgEpBTICM5qkAAUpsZwOpTsKi7qWroAlLQMyBgQYMzuFPrIMbrGRCzhaXDUCWEQxIFUUoxZOeYWBUXUlcit1lB23owI+WRZxhhk2uE0ufWUjq3U0ilSsj5+AR7Boa4QAEyRph3x20mxafRN2UYss45RUBAAbtCUENy2yAYdxg-PUK-lRqZK4LT7IX4vN4-J6QwF0DJDKgjCBjCZTGYeObdSyLZYyeHwoA),
+
+but there is a [TC39 proposal: proposal-deiter](https://github.com/tc39/proposal-deiter) that could make
+destructuring simpler and inlined to
+```ts
+  calculate(...numbers: number[], options: Options) {
+```
+
+#### Example with only positional parameters
+
+```hbs
+{{this.add 1 2 3 4}}
+```
+Because there are no named arguments passed in, the method signature can be simple:
+```js
+class A {
+  add(...numbers: number[]) {
+    // ...
+  }
+}
+```
+
+The implementation for the this function-handling helper-manager could look like this:
+```ts
+import {
+  setHelperManager,
+  capabilities as helperCapabilities,
+} from '@ember/helper';
+import { assert } from '@ember/debug';
+
+class FunctionHelperManager {
+  capabilities = helperCapabilities('3.23', {
+    hasValue: true,
+  });
+
+  createHelper(fn, args) {
+    return { fn, args };
+  }
+
+  getValue({ fn, args }) {
+    let argsForFn = args.positional;
+
+    if (Object.keys(args.named).length > 0) {
+      argsForFn.push(args.named);
+    }
+
+    return fn(...argsForFn);
+  }
+
+  getDebugName(fn) {
+    return fn.name || '(anonymous function)';
+  }
+}
+
+const DEFAULT_HELPER_MANAGER = new FunctionHelperManager();
+
+// side-effect -- this file needs to be imported for the helper manager to be installed
+setHelperManager(() => DEFAULT_HELPER_MANAGER, Function.prototype);
+```
+
+### Modifiers
+
+Modifiers' default should be similar to the Helpers' default, in that they would be function-based.
+The primary difference is that the first argument to a function-modifier is the attached `Element`,
+and the function-modifier _may_ return a destruction function.
+
+Example:
+```js
+class MyComponent {
+  wiggle(element, first, second, options) {
+    const doAnimation = { /* ... */ }
+
+    element.addEventListener('touchstart', doAnimation);
+
+    return () => element.removeEventListener('touchstart', doAnimation);
+  }
+}
+```
+```hbs
+<button {{this.wiggle "first arg" "second arg"}}>
+```
+Similar to the helper manager, because the invocation of `{{this.wiggle ...` has no named arguments,
+the last parameter in the `wiggle` function signature will be `undefined`.
+
+The implementation of this modifier manager could look like:
+
+```js
+import {
+  setModifierManager,
+  capabilities as modifierCapabilities,
+} from '@ember/modifier';
+import { destroy, registerDestructor } from '@ember/destroyable';
+import { setOwner } from '@ember/application';
+
+class DefaultModifierManager {
+  capabilities = modifierCapabilities('3.22');
+
+  createModifier(fn, args) {
+    return { fn, args, element: undefined, destructor: undefined };
+  }
+
+  installModifier(state, element) {
+    state.element = element;
+    this.setupModifier(state);
+  }
+
+  updateModifier(state) {
+    this.destroyModifier(state);
+    this.setupModifier(state);
+  }
+
+  setupModifier(state) {
+    let { fn, args, element } = state;
+
+    let argsForFn = args.positional;
+
+    if (Object.keys(args.named).length > 0) {
+      argsForFn.push(args.named);
+    }
+
+    state.destructor = fn(element, ...argsForFn);
+  }
+
+  destroyModifier(state) {
+    if (typeof state.destructor === 'function') {
+      state.destructor();
+    }
+  }
+}
+
+const DEFAULT_MODIFIER_MANAGER = new DefaultModifierManager();
+
+// side-effect -- this file needs to be imported for the modifier manager to be installed
+setModifierManager(() => DEFAULT_MODIFIER_MANAGER, Function.prototype);
+```
+
+
+### Components
+
+The default component manager could be similar to the component manager for `@glimmer/component`,
+but be compatible with vanilla classes, such as:
+```js
+class MyComponent {
+  @tracked count = 0;
+}
+```
+Since the introduction of `@ember/destroyable`, we no longer _need_ a specific class for helping
+with destruction.
+
+If a component wanted to have a destruction hook, it could register one itself during construction:
+```js
+import { registerDestructor } from '@ember/destroyable';
+
+export default MyComponent {
+  constructor(...args) {
+    super(...args);
+
+    registerDestructor(this, () => this.myDestroy)
+  }
+
+  myDestroy() { /* ... */ }
+}
+```
+
+and the component manager to support this could look like:
+
+```js
+import { setComponentManager } from '@ember/component';
+import { destroy } from '@ember/destroyable';
+
+class DefaultComponentManager {
+  constructor(owner) { this.owner = owner; }
+
+  createComponent(ComponentClass, args) {
+    return new ComponentClass(this.owner, args);
+  }
+
+  getContext(component) {
+    return component;
+  }
+
+  destroyComponent(component) {
+    destroy(component);
+  }
+}
+
+// side-effect -- this file needs to be imported for the component manager to be installed
+setComponentManager((owner) => new DefaultComponentManager(owner), Object.constructor);
+```
+
 
-> 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
 
@@ -93,19 +309,31 @@ 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.
+For helpers and modifiers, there could be some awkwardness around the last argument
+passed to the function, as the type signature may not match how the call-site expects
+the signature to be. Projects like [Glint](https://github.com/typed-ember/glint#readme)
+would be essential for helping with clarity here.
+
+For components, people may begin to ask if they even need `@glimmer/component`, and that's
+something that the core team may want to address -- some folks may feel like there is churn
+in the component base-class, and don't know "what is correct", etc. The two approaches are
+similar enough where we could introduce a migration via lint rule or codemod.
 
 ## Alternatives
 
-> What other designs have been considered? What is the impact of not doing this?
+There are other defaults we could have:
+ - class based helpers & modifiers
+ - function based-components (though this would force the introduction of new paradigms, e.g.: React's hooks)
+    - React's hooks + ember's reactivity _may_ be something with exploring further and there have been a couple
+      of experiments already:
+      - https://github.com/rwjblue/ember-functional-component
+      - https://github.com/lifeart/hooked-components
+      - https://github.com/NullVoxPopuli/ember-function-component
 
-> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
+I don't think any of the above alternatives appeal to the goal of "least surprise" when authoring each of these
+constructs.
 
 ## Unresolved questions
 
-> Optional, but suggested for first drafts. What parts of the design are still
 TBD?

From ef0614af34e098207911459a42be8011438cd44f Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Mon, 21 Jun 2021 23:08:02 -0400
Subject: [PATCH 3/8] Add 'how we teach this'

---
 text/0000-default-managers.md | 38 +++++++++++++++++++++++++++--------
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/text/0000-default-managers.md b/text/0000-default-managers.md
index cb1491b07c..7acaa61443 100644
--- a/text/0000-default-managers.md
+++ b/text/0000-default-managers.md
@@ -296,16 +296,38 @@ setComponentManager((owner) => new DefaultComponentManager(owner), Object.constr
 
 ## 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?
+### Changes to Existing Pages
+
+On the [Helper Functions](https://guides.emberjs.com/v3.26.0/components/helper-functions/) page,
+We'll want to insert a section early on about how helpers can be "local" to or defined on
+components and controllers. Then, once there have been examples of the local/private helper,
+the existing content can continue to talk about the "global helper" -- explicitly differentiating
+between the local/private helper, rather then retaining the general "Helper Function" title as
+"Helper Functions" are all of these, rather than just the globally defines ones.
+
+### Additional Pages
+
+This RFC adopts a default modifier manager, which means that folks can use modifiers without
+the assistance of a third-party addon, such as ember-modifier. This means that we'll benefit from
+adding a page to the guides on modifiers, their philosophy, when to use them, etc. While the
+overall API for modifiers in general has been "not perfect", there has been a fair amount of
+experimentation with modifiers since the 3.11 - 3.16 (pre-octane) era. Function modifiers are
+significantly simpler than class-based modifiers, and the complexity of the specifics of class-
+based modifiers is where most of the hesitance around adding modifiers by default has been.
+
+The default component manager may not need its own guides-documentation, because the prevelance
+of `@glimmer/component` is so widespread, documenting yet-another-way-to-define-a-component may
+cause more harm than good.
+
+Existing users of Ember should be made aware of these capabilities, once implemented, via
+the release blog post, with some examples -- but folks watching developments in the ecosystem
+will likely be aware of ember-could-get-used-to-this and ember-modifier, which both implement
+some parts of this RFC, so the migration path for users of those addons should be straight-forward.
+Those addons _may_ want to deprecate their similar functionality after the proposed behavior here
+lands -- though, this RFC suggests implementation such that developers may still use both
+addons without disruption.
 
-> 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
 

From cafbba3c6478ee47d7611f91b3c7997784b90d72 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Tue, 22 Jun 2021 13:26:39 -0400
Subject: [PATCH 4/8] Update RFC info

---
 text/{0000-default-managers.md => 0754-default-managers.md} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename text/{0000-default-managers.md => 0754-default-managers.md} (99%)

diff --git a/text/0000-default-managers.md b/text/0754-default-managers.md
similarity index 99%
rename from text/0000-default-managers.md
rename to text/0754-default-managers.md
index 7acaa61443..3306253513 100644
--- a/text/0000-default-managers.md
+++ b/text/0754-default-managers.md
@@ -1,6 +1,6 @@
 - Start Date: 2021-05-17
 - Relevant Team(s): Ember.js, Learning
-- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)
+- RFC PR: https://github.com/emberjs/rfcs/pull/754
 - Tracking: (leave this empty)
 
 # Default Managers

From 0d53e252d6f6d7f80d9750a82a68ddefd471fe5e Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Tue, 22 Jun 2021 13:32:23 -0400
Subject: [PATCH 5/8] Update RFC info

---
 text/0754-default-managers.md | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/text/0754-default-managers.md b/text/0754-default-managers.md
index 3306253513..1b84966dc9 100644
--- a/text/0754-default-managers.md
+++ b/text/0754-default-managers.md
@@ -1,7 +1,13 @@
-- Start Date: 2021-05-17
-- Relevant Team(s): Ember.js, Learning
-- RFC PR: https://github.com/emberjs/rfcs/pull/754
-- Tracking: (leave this empty)
+---
+Stage: Accepted
+Start Date: 2021-05-17
+Release Date: Unreleased
+Release Versions:
+  ember-source: vX.Y.Z
+  ember-data: vX.Y.Z
+Relevant Team(s): Ember.js, Learning
+RFC PR: https://github.com/emberjs/rfcs/pull/754
+---
 
 # Default Managers
 

From 62321b9cc08879f8f234947f05c733b24a5812ad Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Sun, 27 Jun 2021 18:25:27 -0400
Subject: [PATCH 6/8] Respond to feedback, add drawback, clarification, etc

---
 text/0754-default-managers.md | 69 ++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/text/0754-default-managers.md b/text/0754-default-managers.md
index 1b84966dc9..99edab54b1 100644
--- a/text/0754-default-managers.md
+++ b/text/0754-default-managers.md
@@ -86,6 +86,10 @@ if (noExistingManagerFor(X)) {
 ```
 Where X is one of a Helper, Modifier, or Component
 
+_A Default Manager is not something that can be chosen by the user, but is baked in to the framework
+as a default so that a user doesn't have to build something to use a non-framework-specific variant
+of the three constructs: Helpers, Modifiers, and Components._
+
 ### Helpers
 
 Borrowing most of the implementation from ember-could-get-used-to-this with one change: the signature
@@ -298,7 +302,66 @@ class DefaultComponentManager {
 setComponentManager((owner) => new DefaultComponentManager(owner), Object.constructor);
 ```
 
-
+### How a template syntax plays in to this behavior
+
+In the current state of templates there is some ambiguity in syntax around helper/component invocation invocation.
+Below is a list exploring the various syntaxes and how the code implemented in the framework for this RFC
+will react to various passed value/function/etc types.
+
+- `{{val}}`
+  - `typeof val === 'function'`: Helper
+    - presently, it's possible to have curly components use this syntax as well. By defining this as a helper,
+      the possibility of using functions as components using curly syntax is eliminated. Curly components could still
+      be used with a base class.
+    - because angle-bracket invocation is the generally accepted way to invoke a component,
+      this may be an acceptable trade-off
+  - `typeof val === 'object'`: Value, rendered
+  - `val instanceof AnyClass`: Value, rendered
+    - Today, classes are `.toString()`'d, but it's feasible that one could define their own
+      custom helper manager or component manager to do something different.
+- `{{ (val) }}`
+  - `typeof val === 'function'`: Helper, existing behavior
+  - `typeof val === 'object'`: Expected Helper error, no manager found
+  - `val instanceof AnyClass`: Expected Helper, no manager found
+- `{{val arg}}`
+  - `typeof val === 'function'`: Helper, existing behavior
+    - Similar to `{{val}}`, it is possible today to define a component manager that takes positional args that
+      would be invoked with this syntax.
+  - `typeof val === 'object'`: Expected Helper error
+  - `val instanceof AnyClass`: Expected Helper, no manager found
+- `<val />`
+  - `typeof val === 'function'`: Component
+    - both functions and classes have `typeof val === 'function'`, so having a default
+      Component Manager that uses classes doesn't prevent the possibility of someone
+      wanting to use functions as components
+  - `typeof val === 'object'`: Expected Component Manager missing error
+  - `val instanceof AnyClass`: Component, because any class can be a component with the proposed
+    default component manager
+- `<Component @arg={{val arg}} />`
+  - `typeof val === 'function'`: Helper, existing behavior
+  - `typeof val === 'object'`: Expected Helper error
+  - `val instanceof AnyClass`: Expected Helper, no manager found
+- `<Component @arg={{val}} />`
+  - `typeof val === 'function'`: Value
+    - if this were to evaluate as a helper it would break existing behavior where you may be
+      passing an event handler to the component
+    - another consequence of evaluating `val` as a helper and invoking it is that it would be
+      more likely to cause an infinite revalidation assertion, which at present, would be hard
+      to track down the source of, but may be an option if the VM one day has an equivalent to
+      React's ErrorBoundary
+    - if someone wanted to invoke `val` as a helper when passed as an argument, they would need to
+      add surrounding `()`, example: `<Component @arg={{ (val) }}` />
+  - `typeof val === 'object'`: Passed as argument to the component
+  - `val instanceof AnyClass`: Passed as argument to the component
+- `<Component @arg={{val 1}} />`
+  - `typeof val === 'function'`: Helper, existing behavior
+  - `typeof val === 'object'`: Expected Helper error
+  - `val instanceof AnyClass`: Expected Helper, no manager found
+- `<div {{val}}>`
+  - `typeof val === 'function'`: Modifier, existing behavior
+  - `val instanceof AnyClass`: Expected Modifier, no manager found
+  - `typeof val !== 'function'`: Expected Modifier error
+  - the behavior of modifiers is unchanged, as there is no ambiguity possible at this time
 
 ## How we teach this
 
@@ -348,6 +411,10 @@ something that the core team may want to address -- some folks may feel like the
 in the component base-class, and don't know "what is correct", etc. The two approaches are
 similar enough where we could introduce a migration via lint rule or codemod.
 
+This proposal eliminates the possibility of using functions as components with the curly
+bracket syntax. However, using functions as components would still be possible with angle bracket
+invocation.
+
 ## Alternatives
 
 There are other defaults we could have:

From e159de8383186aeba9895254b577034b595f2f6f Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Sun, 27 Jun 2021 18:37:46 -0400
Subject: [PATCH 7/8] Add _more_ clarity to the
 helper-as-function-passed-to-component situation (and add Unresolved
 question)

---
 text/0754-default-managers.md | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/text/0754-default-managers.md b/text/0754-default-managers.md
index 99edab54b1..2cdd2545e4 100644
--- a/text/0754-default-managers.md
+++ b/text/0754-default-managers.md
@@ -354,6 +354,14 @@ will react to various passed value/function/etc types.
   - `typeof val === 'object'`: Passed as argument to the component
   - `val instanceof AnyClass`: Passed as argument to the component
 - `<Component @arg={{val 1}} />`
+  - `typeof val === 'function'`: Helper, existing behavior
+    - another consequence of evaluating `val` as a helper and invoking it is that it would be
+      more likely to cause an infinite revalidation assertion, which at present, would be hard
+      to track down the source of, but may be an option if the VM one day has an equivalent to
+      React's ErrorBoundary
+  - `typeof val === 'object'`: Expected Helper error
+  - `val instanceof AnyClass`: Expected Helper, no manager found
+- `<Component @arg={{ (val 1) }} />`
   - `typeof val === 'function'`: Helper, existing behavior
   - `typeof val === 'object'`: Expected Helper error
   - `val instanceof AnyClass`: Expected Helper, no manager found
@@ -415,6 +423,17 @@ This proposal eliminates the possibility of using functions as components with t
 bracket syntax. However, using functions as components would still be possible with angle bracket
 invocation.
 
+The difference between `<Component @handler={{this.handler}} />` and `<Component @handler={{this.handler 1}} />`
+could awkward for folks, as this proposal suggests that curly braces on a component _always_ pass
+a value, _unless_ there are arguments added within the curly braces, in which `this.handler` is invoked
+and the return value is instead passed as `@handler`. This could lead to infinite revalidation assertions,
+which, without an ErrorBoundary (from React) and Error messages that show the location in the template
+where an error originates from, would be fairly hard to track down. One option would be to throw
+an error when `@arg={{this.functionHelper 1}}` is detected, but that would be a breaking change.
+Maybe,
+  To curry: `@arg={{fn this.functionHelper 1}}`
+  To invoke: `@arg={{ (this.functionHelper 1) }}`
+
 ## Alternatives
 
 There are other defaults we could have:
@@ -431,4 +450,7 @@ constructs.
 
 ## Unresolved questions
 
-TBD?
+What do we do about the `@arg={{this.function 1}}` situation? do we just let it invoke (to be consistent),
+and make sure that the infinite revalidation assertion says exactly where the error originates from?
+
+

From 98639c6ba13b9e2690420285f6b63fd342331dec Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <LPSego3+dev@gmail.com>
Date: Tue, 13 Jul 2021 09:09:08 -0400
Subject: [PATCH 8/8] Clarify non-drawbacks of template strict mode

---
 text/0754-default-managers.md | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/text/0754-default-managers.md b/text/0754-default-managers.md
index 2cdd2545e4..6a807cb4f0 100644
--- a/text/0754-default-managers.md
+++ b/text/0754-default-managers.md
@@ -306,7 +306,8 @@ setComponentManager((owner) => new DefaultComponentManager(owner), Object.constr
 
 In the current state of templates there is some ambiguity in syntax around helper/component invocation invocation.
 Below is a list exploring the various syntaxes and how the code implemented in the framework for this RFC
-will react to various passed value/function/etc types.
+will react to various passed value/function/etc types. All of this is current behavior and this RFC is not proposing
+a syntax change. In template strict mode, there is no ambiguity to worry about.
 
 - `{{val}}`
   - `typeof val === 'function'`: Helper
@@ -428,11 +429,9 @@ could awkward for folks, as this proposal suggests that curly braces on a compon
 a value, _unless_ there are arguments added within the curly braces, in which `this.handler` is invoked
 and the return value is instead passed as `@handler`. This could lead to infinite revalidation assertions,
 which, without an ErrorBoundary (from React) and Error messages that show the location in the template
-where an error originates from, would be fairly hard to track down. One option would be to throw
-an error when `@arg={{this.functionHelper 1}}` is detected, but that would be a breaking change.
-Maybe,
-  To curry: `@arg={{fn this.functionHelper 1}}`
-  To invoke: `@arg={{ (this.functionHelper 1) }}`
+where an error originates from, would be fairly hard to track down. The problem goes away entirely in
+template strict mode, so it may not be something we want to worry about in the short-term (outside of
+documenting the possibility and what to do when the situation occurs)
 
 ## Alternatives