please consider different syntax for replacement targets

[getify]

I'm concerned about the readability hazard of the current proposed syntax for named string replacement targets:

let result = '2015-01-02'.replace(re, '$<day>/$<month>/$<year>');

First, the common usage of ' is so close to ` that it will be very easy to visually mistake that as an interpolated string (aka template string). That's made much worse if the suggested alternative of ${ .. } syntax is used, so please don't do that.

But as an anecdote of the readability hazard, before I read the surrounding text explaining, I glanced at the code snippet, and my brain thought the < was a typo for { and the ' was a `, and that the intent of the proposal was to use template strings (which I was immediately going to scoff at, until I read the text). I can't imagine I'll be the only one who may, on glancing at code, get confused.

I understand all the nice symmetry and reasons why. But I think this readability hazard leans in favor of a more-different syntax.

Would you consider any of these options (or something like them)?

let result = '2015-01-02'.replace(re, '@{day}/@{month}/@{year}');

let result = '2015-01-02'.replace(re, '#{day}/#{month}/#{year}');

let result = '2015-01-02'.replace(re, '$day$/$month$/$year$');

[littledan]

@getify Replacement strings already make heavy use of $. The syntax here is intended to stay consistent with that convention. The <> is a nod to the way that groups are contained in those brackets in the RegExp as well as backreferences.

This proposal is at Stage 3 and already has two browser preview implementations. I'd rather not make changes at this point due to programmer intuition/language design concerns, and keep things limited at this point to what's driven by implementations. I'd invite you to take a closer look at the features a little earlier in the development process to provide your feedback earlier on.

[getify]

I'd invite you to take a closer look at the features a little earlier in the development process to provide your feedback earlier on.

Sure, I wish I had read this proposal earlier. I'm busy (as is/are everybody else), and I'm not even on TC39 so it's not directly in my job responsibility to read all the proposals under consideration. As a JS teacher, I try to keep up with it as much as I can, but that's pretty limited, obviously.

With all due respect, I don't think the timeliness, or lack thereof, of my feedback is a weakness of that feedback. If this feature already hit stage 4 and shipped and people had code relying on it, obviously that would be a different story. But, this is still in progress, and I think such feedback is still fair game.

programmer intuition/language design concerns

These should always be germane to discussion.

I know I'm just one person, but I interface with literally thousands of JS developers, of all levels of learning/skill, in my capacity as a JS teacher. I would like to think that does (slightly) inform my intuition. But I certainly didn't claim it was anything other than that.

As a matter of fact, the longer something has been around and "shipped" in some implementations for testing, the far more likely it is to start getting feedback from actual users (like me) who try out the code and find that it's not preferable (in this case, readability wise).

If anything, I think more weight should be given to such concerns the further into a process something is. On day 1, before anyone's had a chance to think about it or even test any real code, that kind of feedback is more like premature bikeshedding. But now, it's very concrete and important to consider (even if it's ultimately rejected).

Replacement strings already make heavy use of $

Yes, I know, I asserted exactly that in my OP. That's precisely my concern... IMO this approach overlaps in a way that betrays the attempt at consistency with muddied confusion instead.

[littledan]

Thanks for taking the time to write this feedback. If we don't make features stable at some point, it will be hard to convince browsers to implement them. I think I need to do more outreach in earlier stages to get this feedback sooner, but at some point we have to restrict changes or it will never get shipped.

I'll take an action item to do more to get more eyes on proposals like this before they reach Stage 3. I wrote a contributing guide to explain how to get involved, but more than that is still needed.

Yes, I know, I asserted exactly that in my OP. That's precisely my concern...

I wasn't talking about template strings but actual replacement strings--the ssecond argument to String.prototype.replace has had $ as the only initial special character since ES3. Adding new special characters runs the risk of making it difficult to evolve programs; in particular, old libraries are more likely to break on new RegExps that use named groups.