(Repost from IRC discussion)

Could do something like this:

```javascript

let re = /```<linefeed>
    (\d{3}-)?    # area code (opt)
    \d{3}-        # exchange
    \d{4}         # line number
```/;

```

It looks sort of heredoc-ish, which is nice, and it shouldn’t break existing  parsing rules.

RegularExpressionLiteral: /``` LineTerminator RegularExpressionBody[SpacingAndComments] ```/ RegularExpressionFlags

This is a PrimaryExpression, and therefore should not be confused with TemplateLiterals, or MultiplicativeExpressions. And because of the required linefeed,
should not break any existing RegularExpressionLiterals.

Just throwing it out there as a possibility.

The 3 backticks is a cute idea, but it probably doesn’t matter how it’s represented. It just looks very heredoc-ish, and distinct from TemplateLiterals.

> On Nov 6, 2015, at 12:28 PM, Brian Terlson <Brian.Terlson at microsoft.com> wrote:
> 
> While looking in to proposals for look-behinds and named capture groups for ECMAScript RegExps, I thought I’d also think about other oft-requested features we currently lack: free-spacing and comments. Comments allow a programmer to embed comments inside the regexp literal. Free-spacing tells the RegExp engine to ignore spaces, tabs, and line breaks. These two features go really nicely together to allow human readable regexps – different parts of a pattern can be split into separate lines with comments on each line describing what it matches. XRegExp supports both of these features as well as the RegExp engines in Perl, Java, C# and others.
> 
> One challenge with supporting free-spacing in ECMAScript is that we don’t allow line breaks inside our regexp literal and constructing regexps from strings is somewhat annoying. The best we could have right now (I think) is something like:
> 
> ```
> let re = new RegExp(String.raw`
>     (\d{3}-)?    # area code (optional)
>     \d{3}-    # prefix
>     \d{4}     # line number
> `, "x");
> ```
> 
> I think this is still a win for long confusing patterns, but maybe I’m alone! Is free-spacing and comments still reasonable if we have to use string templates? Or is there a nice way to extend the grammar of regular expression literals to allow for line breaks? (Eg. maybe we only allow free-spacing with a mode specifier like (?x) inside the pattern?) Any other thoughts?
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151106/450e1e46/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151106/450e1e46/attachment-0001.sig>

(Repost from IRC discussion)

Could do something like this:

```javascript

let re = /```<linefeed>
    (\d{3}-)?    # area code (opt)
    \d{3}-        # exchange
    \d{4}         # line number
```/;

```

It looks sort of heredoc-ish, which is nice, and it shouldn’t break existing  parsing rules.

```js
RegularExpressionLiteral: /``` LineTerminator RegularExpressionBody[SpacingAndComments] ```/ RegularExpressionFlags
```

This is a PrimaryExpression, and therefore should not be confused with TemplateLiterals, or MultiplicativeExpressions. And because of the required linefeed,
should not break any existing RegularExpressionLiterals.

Just throwing it out there as a possibility.

The 3 backticks is a cute idea, but it probably doesn’t matter how it’s represented. It just looks very heredoc-ish, and distinct from TemplateLiterals.