Description

Description of Linked Ticket

The query team has discussed and agreed on the following syntax:

Name $replaceAll

Rejected alternate names: $stringReplace, $substringReplace, $replaceSubstring, $stringReplaceAll

It takes in three expressions that must evaluate to strings: an original string, a string to search for, and a string to insert. This would evaluate to a new string with all occurrences of `find` in `input` replaced by `replacement`. Expressions in each argument would first be evaluated and an error thrown if any input evaluates to a non-string, non-nullish type. Next, if any evaluate to null, the expression evaluates to null.

Because this is a searching algorithm and not a direct string comparison, this computation will not consider the operation's collation. This is consistent with other similar expressions like $indexOfCP and $regexFind. Like these other searching expressions, there will be no unicode normalization. This means that a character like 'é' may not be considered a match if the input string represents it as one unicode character and the 'find' string represents it as two characters: a normal 'e' and a combining diacritical mark.

Syntax:

{ $replaceAll: { input: <Expression>, find: <Expression>, replacement: <Expression> } }

Rejected syntax:

{ $replace: [ <Expression | input>, <Expression | find>, <Expression | replace> ] }

For now we will only support strings as all arguments, we will error on other types.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)