From f933193aaa809afc5e0639bc90b3516597d5f094 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Wed, 16 Nov 2022 09:45:43 -0500 Subject: [PATCH 01/15] Update logical operators --- 0000-update-logical-operators.md | 81 ++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 0000-update-logical-operators.md diff --git a/0000-update-logical-operators.md b/0000-update-logical-operators.md new file mode 100644 index 0000000000..b89708809d --- /dev/null +++ b/0000-update-logical-operators.md @@ -0,0 +1,81 @@ +--- +stage: accepted +start-date: 11/16/2022 +release-date: +release-versions: +teams: # delete teams that aren't relevant + - framework + - learning + - steering + - typescript +prs: + accepted: # update this to the PR that you propose your RFC in +project-link: +--- + + + +# + +## Summary + +As part of RFC 0562, logical operators `and`, `or` and `not` were added to Ember.js. They need to be updated to follow javascript's version of truthy and falsy. + +## Motivation + +Due to the original RFC supporting a different version of truthy/falsy than javascript(i.e. handlebars version), we would need to make a no win decision with two options. + +1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work +2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for the types to be correct + +The same issues follow for the `{{or}}` and `{{not}}` helpers. + +## Detailed design + +Modify {{and}}, {{or}} and {{not}} helpers. + +By changing support of these helpers from handlebars version of truthy/falsy to javascript's version we allow typescript to narrow properly and more closely align ourselves with the main JS community. + +Our definition of falsy would then become `type Falsy = false | 0 | '' | null | undefined;` (as compared to `Falsy = false | 0 | '' | null | undefined | [];` from RFC 0562) + +### {{and}} +Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is not truthy (by javascript's definition of truthiness) or the right-most arguments if all evaluate to truthy. This is equivalent to the {{and}} helper from ember-truth-helpers. Doing this would allow `{{and}}` to compile down to `&&` and give us the correct type safety and narrowing that users would expect. + +### {{or}} +Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to falsy. This is equivalent to the {{or}} helper from ember-truth-helpers. Doing this would allow `{{or}}` to compile down to `||` and give us the correct type safety and narrowing that users would expect. + +### {{not}} +Unary operator. Raises an error if invoked with more than one positional argument. If the given value evaluates to a truthy value (by javscript's definition of truthiness), the false is returned. If the given value evaluates to a falsy value (by javascript's definition of truthiness) then it returns true. This is equivalent to the {{not}} helper from ember-truth-helpers. Doing this would allow `{{not}}` to compile down to `!` and give us the correct type safety and narrowing that users would expect. + + +## How we teach this + +While the introduction of these helpers doesn't introduce new concepts, as helpers like these could be written and in fact were written for a long time, it might affect slightly how we frame some concepts in the guides. + +Previously users were encouraged to put computed properties in the javascript file of the components, even for the most simple tasks like negating a boolean condition using computed.not or adding them with computed.and. + +With the addition of these helpers users don't have to resort to computed properties for simple operations, which sometimes forced users to create javascript files for what could have been template-only components. + +In addition to documenting the new helpers in the API docs, the Guides should be updated to favour the usage of helpers over computed properties where it makes more sense, adding illustrative examples and stressing out where the definition of truthiness of handlebars differs from the one of Javascript. + +## Drawbacks + +We further separate ourselves from handlebars by not supporting `[]` as a falsy value. This makes the learning curve for `HTMLBars` (our version) just a little steeper when coming from handlebars + +## Alternatives + +One alternative involves supporting `[]` as falsy value and just trying to teach users that your types wont be correct or narrow properly. + +## Unresolved questions + From 5435609f150bf3694b6e8c546e5fb7bf3d2e5ab8 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Wed, 16 Nov 2022 10:32:21 -0500 Subject: [PATCH 02/15] Modify RFC to be global across all operators --- ...e-glimmer-template-truthiness-semantics.md | 106 ++++++++++++++++++ 0000-update-logical-operators.md | 81 ------------- 2 files changed, 106 insertions(+), 81 deletions(-) create mode 100644 0000-update-glimmer-template-truthiness-semantics.md delete mode 100644 0000-update-logical-operators.md diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md new file mode 100644 index 0000000000..67914c816a --- /dev/null +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -0,0 +1,106 @@ +--- +stage: accepted +start-date: 11/16/2022 +release-date: +release-versions: +teams: # delete teams that aren't relevant + - framework + - learning + - steering + - typescript +prs: + accepted: # update this to the PR that you propose your RFC in +project-link: +--- + + + +# Update Glimmer Template Truthiness Semantics + +## Summary + +Update truthiness semantics from handlebar's version to javascript's version to allow for typescript to work as users would expect it to + +## Motivation + +Due to handlebars supporting a different truthiness semantics than javascript, typescript cant function like users would expect it to. +By aligning HTMLBars version of truthiness semantics with the wider javascript community, type checking will function as users expect. + +To give an example of why this is an issue we can use the `{{and}}` operator. Right now we have a choice without changing the implementation of truthiness semantics in our templates. +1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work +2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for the types to be correct + +## Detailed design + +Modify `{{and}}`, `{{or}}`, `{{not}}`, `{{if}}` and `{{unless}}` helpers. Clarify internal workings of `{{eq}}`, `{{neq}}`, `{{lt}}`, `{{lte}}`, `{{gt}}`, `{{gte}}` + +By changing support of these helpers from handlebars truthiness semantics to javascript's truthiness semantics we allow typescript to narrow properly and more closely align ourselves with the main JS community. + +Our definition of falsy would then become `type Falsy = false | 0 | '' | null | undefined;` as compared to handlebars version of `Falsy = false | 0 | '' | null | undefined | [];` + +### {{and}} +Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is not truthy (by javascript's definition of truthiness) or the right-most arguments if all evaluate to truthy. This is equivalent to the {{and}} helper from ember-truth-helpers. Doing this would allow `{{and}}` to compile down to `&&` and give us the correct type safety and narrowing that users would expect. + +### {{or}} +Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to falsy. This is equivalent to the {{or}} helper from ember-truth-helpers. Doing this would allow `{{or}}` to compile down to `||` and give us the correct type safety and narrowing that users would expect. + +### {{not}} +Unary operator. Raises an error if invoked with more than one positional argument. If the given value evaluates to a truthy value (by javscript's definition of truthiness), the false is returned. If the given value evaluates to a falsy value (by javascript's definition of truthiness) then it returns true. This is equivalent to the {{not}} helper from ember-truth-helpers. Doing this would allow `{{not}}` to compile down to `!` and give us the correct type safety and narrowing that users would expect. + +### {{if}} +Same implementation as current `if`. The only difference is when doing the check for truthiness it would follow javascript's truthiness semantics. + +### {{unless}} +Same implementation as current `unless`. The only difference is when doing the check for truthiness it would follow javascript's truthiness semantics. + +### {{eq}} +Binary operation. Throws an error if not called with exactly two arguments. Uses triple equal version of javascript equality. Doing this allows for `{{eq}}` to compile down to `===` and give us the correct type safety and narrowing that users would expect + +### {{neq}} +Binary operation. Throws an error if not called with exactly two arguments. Uses triple not equal version of javascript equality. Doing this allows for `{{neq}}` to compile down to `!==` and give us the correct type safety and narrowing that users would expect + +### {{lt}} +Binary operation. Throws an error if not called with exactly two arguments. Equivalent of `<` in Javascript. + +### {{lte}} +Binary operation. Throws an error if not called with exactly two arguments. Equivalent of `<=` in Javascript. + +### {{gt}} +Binary operation. Throws an error if not called with exactly two arguments. Equivalent of `>` in Javascript. + +### {{gte}} +Binary operation. Throws an error if not called with exactly two arguments. Equivalent of `>=` in Javascript. + +### Migration Plan +1. Ship comparison helpers `and`, `or`, `not` with existing equality and truthiness semantics. +2. Ship types which match that and document why they work they way they do. Acknowledge that this wont work for TS users in they way they would expect and why. +3. Ship ability to opt into new behavior (Following JS truthiness semantics) +4. Ship types that match this new behavior and document why you would have to opt into new behavior +5. As soon as the opt-in ability is shipped and we have had an LTS release - deprecate the old semantics and plan to remove them in the next major version. + + +## How we teach this + +Clearly draw attention to the differences between handlebars truthiness and javascript's in the docs. Explain why we made such a choice and what benefits it gives the end user. + +## Drawbacks + +We further separate ourselves from handlebars by not supporting `[]` as a falsy value. This makes the learning curve for `HTMLBars` (our version) just a little steeper when coming from handlebars + +## Alternatives + +One alternative involves supporting `[]` as falsy value and just trying to teach users that your types wont be correct or narrow properly. + +## Unresolved questions + diff --git a/0000-update-logical-operators.md b/0000-update-logical-operators.md deleted file mode 100644 index b89708809d..0000000000 --- a/0000-update-logical-operators.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -stage: accepted -start-date: 11/16/2022 -release-date: -release-versions: -teams: # delete teams that aren't relevant - - framework - - learning - - steering - - typescript -prs: - accepted: # update this to the PR that you propose your RFC in -project-link: ---- - - - -# - -## Summary - -As part of RFC 0562, logical operators `and`, `or` and `not` were added to Ember.js. They need to be updated to follow javascript's version of truthy and falsy. - -## Motivation - -Due to the original RFC supporting a different version of truthy/falsy than javascript(i.e. handlebars version), we would need to make a no win decision with two options. - -1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work -2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for the types to be correct - -The same issues follow for the `{{or}}` and `{{not}}` helpers. - -## Detailed design - -Modify {{and}}, {{or}} and {{not}} helpers. - -By changing support of these helpers from handlebars version of truthy/falsy to javascript's version we allow typescript to narrow properly and more closely align ourselves with the main JS community. - -Our definition of falsy would then become `type Falsy = false | 0 | '' | null | undefined;` (as compared to `Falsy = false | 0 | '' | null | undefined | [];` from RFC 0562) - -### {{and}} -Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is not truthy (by javascript's definition of truthiness) or the right-most arguments if all evaluate to truthy. This is equivalent to the {{and}} helper from ember-truth-helpers. Doing this would allow `{{and}}` to compile down to `&&` and give us the correct type safety and narrowing that users would expect. - -### {{or}} -Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to falsy. This is equivalent to the {{or}} helper from ember-truth-helpers. Doing this would allow `{{or}}` to compile down to `||` and give us the correct type safety and narrowing that users would expect. - -### {{not}} -Unary operator. Raises an error if invoked with more than one positional argument. If the given value evaluates to a truthy value (by javscript's definition of truthiness), the false is returned. If the given value evaluates to a falsy value (by javascript's definition of truthiness) then it returns true. This is equivalent to the {{not}} helper from ember-truth-helpers. Doing this would allow `{{not}}` to compile down to `!` and give us the correct type safety and narrowing that users would expect. - - -## How we teach this - -While the introduction of these helpers doesn't introduce new concepts, as helpers like these could be written and in fact were written for a long time, it might affect slightly how we frame some concepts in the guides. - -Previously users were encouraged to put computed properties in the javascript file of the components, even for the most simple tasks like negating a boolean condition using computed.not or adding them with computed.and. - -With the addition of these helpers users don't have to resort to computed properties for simple operations, which sometimes forced users to create javascript files for what could have been template-only components. - -In addition to documenting the new helpers in the API docs, the Guides should be updated to favour the usage of helpers over computed properties where it makes more sense, adding illustrative examples and stressing out where the definition of truthiness of handlebars differs from the one of Javascript. - -## Drawbacks - -We further separate ourselves from handlebars by not supporting `[]` as a falsy value. This makes the learning curve for `HTMLBars` (our version) just a little steeper when coming from handlebars - -## Alternatives - -One alternative involves supporting `[]` as falsy value and just trying to teach users that your types wont be correct or narrow properly. - -## Unresolved questions - From ae94412c69c98e86eab333716a80ab076c91c974 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Wed, 16 Nov 2022 11:00:57 -0500 Subject: [PATCH 03/15] Expand migration plan to include if and unless --- 0000-update-glimmer-template-truthiness-semantics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 67914c816a..2875b4d90d 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -83,9 +83,9 @@ Binary operation. Throws an error if not called with exactly two arguments. Equi Binary operation. Throws an error if not called with exactly two arguments. Equivalent of `>=` in Javascript. ### Migration Plan -1. Ship comparison helpers `and`, `or`, `not` with existing equality and truthiness semantics. +1. Ship comparison helpers `and`, `or`, `not` with existing equality and truthiness semantics (they currently match `if` and `unless` truthiness semantics) 2. Ship types which match that and document why they work they way they do. Acknowledge that this wont work for TS users in they way they would expect and why. -3. Ship ability to opt into new behavior (Following JS truthiness semantics) +3. Ship ability to opt into new behavior for `and`, `or`, `not`, `if` and `unless` (Following JS truthiness semantics) 4. Ship types that match this new behavior and document why you would have to opt into new behavior 5. As soon as the opt-in ability is shipped and we have had an LTS release - deprecate the old semantics and plan to remove them in the next major version. From 45c129f99d4a8d02220da2f503b9e684d5ee6487 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Wed, 16 Nov 2022 11:13:07 -0500 Subject: [PATCH 04/15] Update 0000-update-glimmer-template-truthiness-semantics.md Modify title Co-authored-by: Chris Krycho --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 2875b4d90d..99e8b9cfb2 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -30,7 +30,7 @@ project-link: Leave as is ## Summary -Update truthiness semantics from handlebar's version to javascript's version to allow for typescript to work as users would expect it to +Provide a path for Glimmer templates to switch away from classic Handlebars truthiness to JavaScript’s truthiness. This will align our templating language with users' expectations and make teaching easier. It will also allow TypeScript features like type narrowing to work as users would expect it to with keywords like `{{and}}` or `{{or}}`. ## Motivation From 88475f4974cfb1a1c51a1864594f19dbb4de50e4 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Fri, 18 Nov 2022 08:10:10 -0500 Subject: [PATCH 05/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Peter Wagenet --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 99e8b9cfb2..3d490f4468 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -39,7 +39,7 @@ By aligning HTMLBars version of truthiness semantics with the wider javascript c To give an example of why this is an issue we can use the `{{and}}` operator. Right now we have a choice without changing the implementation of truthiness semantics in our templates. 1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work -2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for the types to be correct +2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for type guards and narrowing ## Detailed design From eb299a05767de989a19b5ee454a7d20d18bcf2b2 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Fri, 18 Nov 2022 08:10:34 -0500 Subject: [PATCH 06/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Peter Wagenet --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 3d490f4468..4d0c702cea 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -37,7 +37,7 @@ Provide a path for Glimmer templates to switch away from classic Handlebars trut Due to handlebars supporting a different truthiness semantics than javascript, typescript cant function like users would expect it to. By aligning HTMLBars version of truthiness semantics with the wider javascript community, type checking will function as users expect. -To give an example of why this is an issue we can use the `{{and}}` operator. Right now we have a choice without changing the implementation of truthiness semantics in our templates. +To give an example of why this is an issue we can use the `{{and}}` operator. Under the current Glimmer semantics, we can handle TypeScript in one of two ways: 1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work 2) `{{and}}` compiles to `and()` which will allow truthy and falsy values to respect handlebars version of truthy and falsy, but wont allow for type guards and narrowing From e7a10f44af9671cfef0688893bac144b048fec10 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Fri, 18 Nov 2022 08:10:41 -0500 Subject: [PATCH 07/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Peter Wagenet --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 4d0c702cea..4c695dee07 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -35,7 +35,7 @@ Provide a path for Glimmer templates to switch away from classic Handlebars trut ## Motivation Due to handlebars supporting a different truthiness semantics than javascript, typescript cant function like users would expect it to. -By aligning HTMLBars version of truthiness semantics with the wider javascript community, type checking will function as users expect. +By aligning Glimmer's version of truthiness semantics with the wider javascript community, type checking will function as users expect. To give an example of why this is an issue we can use the `{{and}}` operator. Under the current Glimmer semantics, we can handle TypeScript in one of two ways: 1) `{{and}}` compiles to `&&` which will allow TS to lie to us about what is safe and what isn't (and will cause compile time errors) but WILL allow for type guards and narrowing to work From 9f74d6d41671c85fec945358a12fed890caa5ec6 Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Mon, 21 Nov 2022 07:49:45 -0500 Subject: [PATCH 08/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Jon Johnson --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 4c695dee07..2b2230db94 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -84,7 +84,7 @@ Binary operation. Throws an error if not called with exactly two arguments. Equi ### Migration Plan 1. Ship comparison helpers `and`, `or`, `not` with existing equality and truthiness semantics (they currently match `if` and `unless` truthiness semantics) -2. Ship types which match that and document why they work they way they do. Acknowledge that this wont work for TS users in they way they would expect and why. +2. Ship types which match that and document why they work the way they do. Acknowledge that this wont work for TS users in the way they would expect and why. 3. Ship ability to opt into new behavior for `and`, `or`, `not`, `if` and `unless` (Following JS truthiness semantics) 4. Ship types that match this new behavior and document why you would have to opt into new behavior 5. As soon as the opt-in ability is shipped and we have had an LTS release - deprecate the old semantics and plan to remove them in the next major version. From 52cff926448286f4d7d29ca670c34a06258caddc Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Mon, 21 Nov 2022 08:00:38 -0500 Subject: [PATCH 09/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Bert De Block --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 2b2230db94..c0314ac6cd 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -34,7 +34,7 @@ Provide a path for Glimmer templates to switch away from classic Handlebars trut ## Motivation -Due to handlebars supporting a different truthiness semantics than javascript, typescript cant function like users would expect it to. +Due to Handlebars supporting a different truthiness semantics than JavaScript, TypeScript can't function like users would expect it to. By aligning Glimmer's version of truthiness semantics with the wider javascript community, type checking will function as users expect. To give an example of why this is an issue we can use the `{{and}}` operator. Under the current Glimmer semantics, we can handle TypeScript in one of two ways: From c1d885624aa85c42e3d6c5b5d4a39e77c90bd3dc Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Mon, 21 Nov 2022 08:01:09 -0500 Subject: [PATCH 10/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Bert De Block --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index c0314ac6cd..2c5f0c00d6 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -50,7 +50,7 @@ By changing support of these helpers from handlebars truthiness semantics to jav Our definition of falsy would then become `type Falsy = false | 0 | '' | null | undefined;` as compared to handlebars version of `Falsy = false | 0 | '' | null | undefined | [];` ### {{and}} -Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is not truthy (by javascript's definition of truthiness) or the right-most arguments if all evaluate to truthy. This is equivalent to the {{and}} helper from ember-truth-helpers. Doing this would allow `{{and}}` to compile down to `&&` and give us the correct type safety and narrowing that users would expect. +Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is not truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to truthy. This is equivalent to the {{and}} helper from ember-truth-helpers. Doing this would allow `{{and}}` to compile down to `&&` and give us the correct type safety and narrowing that users would expect. ### {{or}} Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to falsy. This is equivalent to the {{or}} helper from ember-truth-helpers. Doing this would allow `{{or}}` to compile down to `||` and give us the correct type safety and narrowing that users would expect. From c0caa6fabd17d50105478b2ae4f3f39b1485178c Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Mon, 21 Nov 2022 08:01:32 -0500 Subject: [PATCH 11/15] Update 0000-update-glimmer-template-truthiness-semantics.md Co-authored-by: Bert De Block --- 0000-update-glimmer-template-truthiness-semantics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 2c5f0c00d6..e775236cbb 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -56,7 +56,7 @@ Takes at least two positional arguments. Raises an error if invoked with less th Takes at least two positional arguments. Raises an error if invoked with less than two arguments. It evaluates arguments left to right, returning the first one that is truthy (by javascript's definition of truthiness) or the right-most argument if all evaluate to falsy. This is equivalent to the {{or}} helper from ember-truth-helpers. Doing this would allow `{{or}}` to compile down to `||` and give us the correct type safety and narrowing that users would expect. ### {{not}} -Unary operator. Raises an error if invoked with more than one positional argument. If the given value evaluates to a truthy value (by javscript's definition of truthiness), the false is returned. If the given value evaluates to a falsy value (by javascript's definition of truthiness) then it returns true. This is equivalent to the {{not}} helper from ember-truth-helpers. Doing this would allow `{{not}}` to compile down to `!` and give us the correct type safety and narrowing that users would expect. +Unary operator. Raises an error if invoked with more than one positional argument. If the given value evaluates to a truthy value (by javscript's definition of truthiness), then false is returned. If the given value evaluates to a falsy value (by javascript's definition of truthiness) then it returns true. This is equivalent to the {{not}} helper from ember-truth-helpers. Doing this would allow `{{not}}` to compile down to `!` and give us the correct type safety and narrowing that users would expect. ### {{if}} Same implementation as current `if`. The only difference is when doing the check for truthiness it would follow javascript's truthiness semantics. From 27d3be08cf050b5eccd6f8cdb21136f3b1e129ab Mon Sep 17 00:00:00 2001 From: Adam Baker Date: Mon, 21 Nov 2022 08:06:03 -0500 Subject: [PATCH 12/15] Remove steering team --- 0000-update-glimmer-template-truthiness-semantics.md | 1 - 1 file changed, 1 deletion(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index e775236cbb..902d1a0688 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -6,7 +6,6 @@ release-versions: teams: # delete teams that aren't relevant - framework - learning - - steering - typescript prs: accepted: # update this to the PR that you propose your RFC in From 0f6417b7406357e12cdbe911d616208af6a8e8cf Mon Sep 17 00:00:00 2001 From: Peter Wagenet Date: Mon, 21 Nov 2022 08:30:28 -0800 Subject: [PATCH 13/15] Whitespace --- 0000-update-glimmer-template-truthiness-semantics.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/0000-update-glimmer-template-truthiness-semantics.md b/0000-update-glimmer-template-truthiness-semantics.md index 902d1a0688..e318181a38 100644 --- a/0000-update-glimmer-template-truthiness-semantics.md +++ b/0000-update-glimmer-template-truthiness-semantics.md @@ -1,7 +1,7 @@ --- stage: accepted start-date: 11/16/2022 -release-date: +release-date: release-versions: teams: # delete teams that aren't relevant - framework @@ -12,8 +12,8 @@ prs: project-link: --- -