Discuss
  • Template literal property names in object literals

Template literal property names in object literals

# Alex Kodat (4 years ago)

Jordan,

The sentiments in that link discuss the wisdom of having the StringLiteral definition include NoSubstitutionTemplate, a question about which I am agnostic, and wouldn't provide the full functionality I'm asking about, anyway.

And I also understand that the spec currently only allows computed property names in square brackets.

My suggestion was that ComputedPropertyName could be changed to include TemplateString (without square brackets). Whether this is worth doing or paints JS syntax into a corner is a fair question, but I don't see that adding TemplateString to ComputedPropertyName would create any syntactic ambiguities and wouldn't seem to present daunting implementation issues. But maybe this last assertion is incorrect and ambiguities would arise or implementation would be a nightmare?

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com

From: Jordan Harband <ljharb at gmail.com>

Sent: Thursday, November 7, 2019 1:46 PM To: Alex Kodat <akodat at rocketsoftware.com>

Cc: Gus Caplan <me at gus.host>; es-discuss at mozilla.org

Subject: Re: Template literal propery names in object literals

Anything dynamic - computed - should be in brackets, since that's what that indicates.

Thus, template literals with substitutions must require brackets.

Based on sentiments like nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399%23issuecomment-452910799&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527965990546&sdata=71bc85j8UPdAdkFjmprrximGsaySHt1o3r8zkV9ZYgQ%3D&reserved=0, either all template literals or none should be permitted in a given position.

Thus, no change is possible.

On Thu, Nov 7, 2019 at 10:00 AM Alex Kodat <mailto:akodat at rocketsoftware.com> wrote:

Thanks Gus,

Good stuff. Though I think I’d take a different tack on the discussion at that link, especially as I think the template literals should allow substitutions (why not?):

let obj = { ${Date()}: 1};

I guess the tack I would take in the spec would be to add TemplateLiteral to ComputedPropertyName and not worry about whether or not it's a NoSubstitutionTemplate.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527965990546&sdata=d62CHuayKkj8EhttWHK9kbMjnnkMGJgrrDbZRjtlul0%3D&reserved=0

From: Gus Caplan <mailto:me at gus.host>

Sent: Thursday, November 7, 2019 11:13 AM To: Alex Kodat <mailto:akodat at rocketsoftware.com>

Cc: mailto:es-discuss at mozilla.org Subject: Re: Template literal propery names in object literals

Related discussion nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527965990546&sdata=8XRONc3vM6asxLzdeGYYKXaqkQ0ltiNzDgBD9en3X7s%3D&reserved=0

On Thu, Nov 7, 2019 at 8:46 AM Alex Kodat <mailto:mailto:akodat at rocketsoftware.com> wrote:

Just curious. Is there a reason template literals are not allowed as property names in object literals? I can do:

let obj = {'foo bar': 1};

and

let obj = {"foo bar": 1};

but not

let obj = {foo bar: 1};

It doesn't seem that allowing the latter would present any syntactic problems and seems like almost an oversight that it's not allowed.

The main reason I ask is that we've gone completely over to using template literals for all our literals (why not?) and was surprised that we can't use a template literal as an object literal property name. Obviously, we can do:

let obj = {[foo bar]: 1};

And given that square brackets allow arbitrary expressions for propery names, it wouldn't seem that supporting template literals for object literal property names would not present any daunting implementation issues.

I guess I'd argue that the Principle of Least Astonishment and/or completeness suggests that JS should support this.

Sorry if this has been asked before but couldn't find anything in the archive.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527966000541&sdata=ZKH85YD9HEKWNt0Gti1IYmywyMwa%2BbtGxSn41xKjt%2FE%3D&reserved=0

================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527966000541&sdata=o2jLB3Up2WN%2FLbYnNp5II%2BwR5MFBcm5%2Bl1ejZ%2Ft%2FJiI%3D&reserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527966010535&sdata=SWWsXjtV0%2Fogzd9pHPHBLt57fuYbxdreIkYRFJ4Qgdc%3D&reserved=0 Privacy Policy - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02|01||a6f02ff84bd446c7593708d763bb3255|79544c1eed224879a082b67a9a672aae|0|0|637087527966010535&sdata=GNQujvYIbGmSbJjpsalm9nb65wqEzHS2L4e2LZerQUc%3D&reserved=0

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

# Jordan Harband (4 years ago)

It would create the ambiguity that "every property name not in brackets is static/hardcoded" is no longer true.

# Alex Kodat (4 years ago)

Jordan,

That’s not an ambiguity, it’s just a rule of thumb that’s currently true. No? My question is whether adding TemplateString to ComputedPropertyName in the spec would create syntactic ambiguities or daunting implementation issues.

Clearly, there's little interest in this so I'll drop it, I was just curious as I, at least, was somewhat surprised to see it didn't work.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com

From: Jordan Harband <ljharb at gmail.com>

Sent: Thursday, November 7, 2019 2:44 PM To: Alex Kodat <akodat at rocketsoftware.com>

Cc: Gus Caplan <me at gus.host>; es-discuss at mozilla.org

Subject: Re: Template literal property names in object literals

It would create the ambiguity that "every property name not in brackets is static/hardcoded" is no longer true.

On Thu, Nov 7, 2019 at 12:14 PM Alex Kodat <mailto:akodat at rocketsoftware.com> wrote:

Jordan,

The sentiments in that link discuss the wisdom of having the StringLiteral definition include NoSubstitutionTemplate, a question about which I am agnostic, and wouldn't provide the full functionality I'm asking about, anyway.

And I also understand that the spec currently only allows computed property names in square brackets.

My suggestion was that ComputedPropertyName could be changed to include TemplateString (without square brackets). Whether this is worth doing or paints JS syntax into a corner is a fair question, but I don't see that adding TemplateString to ComputedPropertyName would create any syntactic ambiguities and wouldn't seem to present daunting implementation issues. But maybe this last assertion is incorrect and ambiguities would arise or implementation would be a nightmare?

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764059583&sdata=uyR3LapBE55WBka7oMxIFinkB3u86hxFdAheaEgOuIo%3D&reserved=0

From: Jordan Harband <mailto:ljharb at gmail.com>

Sent: Thursday, November 7, 2019 1:46 PM To: Alex Kodat <mailto:akodat at rocketsoftware.com>

Cc: Gus Caplan <mailto:me at gus.host>; mailto:es-discuss at mozilla.org

Subject: Re: Template literal propery names in object literals

Anything dynamic - computed - should be in brackets, since that's what that indicates.

Thus, template literals with substitutions must require brackets.

Based on sentiments like nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399%23issuecomment-452910799&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764059583&sdata=Zj9u%2FVXu8niYo87ukf22u8SKdnBh9qCUFTn%2Fe%2FEhczI%3D&reserved=0, either all template literals or none should be permitted in a given position.

Thus, no change is possible.

On Thu, Nov 7, 2019 at 10:00 AM Alex Kodat <mailto:mailto:akodat at rocketsoftware.com> wrote:

Thanks Gus,

Good stuff. Though I think I’d take a different tack on the discussion at that link, especially as I think the template literals should allow substitutions (why not?):

let obj = { ${Date()}: 1};

I guess the tack I would take in the spec would be to add TemplateLiteral to ComputedPropertyName and not worry about whether or not it's a NoSubstitutionTemplate.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764069581&sdata=kubTmB4qf6nllE%2BpEkC93HfSvqqard6q%2BUznl%2B%2FjKjc%3D&reserved=0

From: Gus Caplan <mailto:mailto:me at gus.host>

Sent: Thursday, November 7, 2019 11:13 AM To: Alex Kodat <mailto:mailto:akodat at rocketsoftware.com>

Cc: mailto:mailto:es-discuss at mozilla.org Subject: Re: Template literal propery names in object literals

Related discussion nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764069581&sdata=XONOYQh%2FojUU3RYUpL54XXnPQT7kGFAL7bOWRzJdnBQ%3D&reserved=0

On Thu, Nov 7, 2019 at 8:46 AM Alex Kodat <mailto:mailto:mailto:mailto:akodat at rocketsoftware.com> wrote:

Just curious. Is there a reason template literals are not allowed as property names in object literals? I can do:

let obj = {'foo bar': 1};

and

let obj = {"foo bar": 1};

but not

let obj = {foo bar: 1};

It doesn't seem that allowing the latter would present any syntactic problems and seems like almost an oversight that it's not allowed.

The main reason I ask is that we've gone completely over to using template literals for all our literals (why not?) and was surprised that we can't use a template literal as an object literal property name. Obviously, we can do:

let obj = {[foo bar]: 1};

And given that square brackets allow arbitrary expressions for propery names, it wouldn't seem that supporting template literals for object literal property names would not present any daunting implementation issues.

I guess I'd argue that the Principle of Least Astonishment and/or completeness suggests that JS should support this.

Sorry if this has been asked before but couldn't find anything in the archive.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764079579&sdata=uERLRVxURgftYgRhSQ66kcbkCAg4avY9S2V77mguPMc%3D&reserved=0

================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764079579&sdata=rhudJ7LM7ZLjEGJfQuCLHMc7GaZxsqsP%2BfBgippoG1Q%3D&reserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764089567&sdata=UWwp7D1lSE0H7ziOC0t7FAm8oWe4tcc9vc4U4S35UX0%3D&reserved=0 Privacy Policy - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02|01||57ccd30c5787459e5ad808d763c34c67|79544c1eed224879a082b67a9a672aae|0|0|637087562764089567&sdata=ZZMTzj0emECMbYg%2BClpZ4nadZsIjfRALtbTTX3308F4%3D&reserved=0

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

# Gus Caplan (4 years ago)

Syntactic ambiguities are not very representative of what humans find ambiguous. For example, const x = 1 const x = 2 (no semicolon) is not ambiguous to a parser at all, but humans have a hard time tracking it.

# Alex Kodat (4 years ago)

Gus,

Sure, but your (const) example is simply syntactically invalid – syntactically invalid code will always be hard for humans to digest. A better example might be one involving operator precedence – I’ll plead guilty to adding unnecessary parentheses so someone looking at code doesn’t have to waste cycles thinking through operator precedence issues.

But, in any case, I don't think human would find:

let obj = {foo bar: 1}

or even

let obj = {foo${i}: 1}

daunting to parse. And if it upsets them, just like I add unnecessary parantheses to my code, they could do

let obj = {[foo${i}]: 1}

if they feel that somehow makes the code clearer (it gives me a headache ;-)).

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com

From: Gus Caplan <me at gus.host>

Sent: Thursday, November 7, 2019 3:13 PM To: Alex Kodat <akodat at rocketsoftware.com>

Cc: Jordan Harband <ljharb at gmail.com>; es-discuss at mozilla.org

Subject: Re: Template literal property names in object literals

Syntactic ambiguities are not very representative of what humans find ambiguous. For example, const x = 1 const x = 2 (no semicolon) is not ambiguous to a parser at all, but humans have a hard time tracking it.

On Thu, Nov 7, 2019 at 12:53 PM Alex Kodat <mailto:akodat at rocketsoftware.com> wrote:

Jordan,

That’s not an ambiguity, it’s just a rule of thumb that’s currently true. No? My question is whether adding TemplateString to ComputedPropertyName in the spec would create syntactic ambiguities or daunting implementation issues.

Clearly, there's little interest in this so I'll drop it, I was just curious as I, at least, was somewhat surprised to see it didn't work.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982532174&sdata=wl5HN9LEKavzBGkxJf0SugC2iN2oOQu12kmnXKUkXoo%3D&reserved=0

From: Jordan Harband <mailto:ljharb at gmail.com>

Sent: Thursday, November 7, 2019 2:44 PM To: Alex Kodat <mailto:akodat at rocketsoftware.com>

Cc: Gus Caplan <mailto:me at gus.host>; mailto:es-discuss at mozilla.org

Subject: Re: Template literal property names in object literals

It would create the ambiguity that "every property name not in brackets is static/hardcoded" is no longer true.

On Thu, Nov 7, 2019 at 12:14 PM Alex Kodat <mailto:mailto:akodat at rocketsoftware.com> wrote:

Jordan,

The sentiments in that link discuss the wisdom of having the StringLiteral definition include NoSubstitutionTemplate, a question about which I am agnostic, and wouldn't provide the full functionality I'm asking about, anyway.

And I also understand that the spec currently only allows computed property names in square brackets.

My suggestion was that ComputedPropertyName could be changed to include TemplateString (without square brackets). Whether this is worth doing or paints JS syntax into a corner is a fair question, but I don't see that adding TemplateString to ComputedPropertyName would create any syntactic ambiguities and wouldn't seem to present daunting implementation issues. But maybe this last assertion is incorrect and ambiguities would arise or implementation would be a nightmare?

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982532174&sdata=wl5HN9LEKavzBGkxJf0SugC2iN2oOQu12kmnXKUkXoo%3D&reserved=0

From: Jordan Harband <mailto:mailto:ljharb at gmail.com>

Sent: Thursday, November 7, 2019 1:46 PM To: Alex Kodat <mailto:mailto:akodat at rocketsoftware.com>

Cc: Gus Caplan <mailto:mailto:me at gus.host>; mailto:mailto:es-discuss at mozilla.org

Subject: Re: Template literal propery names in object literals

Anything dynamic - computed - should be in brackets, since that's what that indicates.

Thus, template literals with substitutions must require brackets.

Based on sentiments like nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399%23issuecomment-452910799&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982542161&sdata=V%2BzJuiHgRE6plHXA5lyY4xhlhv4O5%2Fvl6UTc1yeaRzk%3D&reserved=0, either all template literals or none should be permitted in a given position.

Thus, no change is possible.

On Thu, Nov 7, 2019 at 10:00 AM Alex Kodat <mailto:mailto:mailto:mailto:akodat at rocketsoftware.com> wrote:

Thanks Gus,

Good stuff. Though I think I’d take a different tack on the discussion at that link, especially as I think the template literals should allow substitutions (why not?):

let obj = { ${Date()}: 1};

I guess the tack I would take in the spec would be to add TemplateLiteral to ComputedPropertyName and not worry about whether or not it's a NoSubstitutionTemplate.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982542161&sdata=oWJOeksC4idx7j4ffoOjNMiT6oXmY8XmVaAgQJnmHPM%3D&reserved=0

From: Gus Caplan <mailto:mailto:mailto:me at gus.host>

Sent: Thursday, November 7, 2019 11:13 AM To: Alex Kodat <mailto:mailto:mailto:mailto:akodat at rocketsoftware.com>

Cc: mailto:mailto:mailto:mailto:es-discuss at mozilla.org Subject: Re: Template literal propery names in object literals

Related discussion nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982552157&sdata=Lm5ZzlaIBiRhWfI%2B3NM7q6WN4R9zeDtak5eb1L8nD5A%3D&reserved=0

On Thu, Nov 7, 2019 at 8:46 AM Alex Kodat <mailto:mailto:mailto:mailto:mailto:mailto:mailto:akodat at rocketsoftware.com> wrote:

Just curious. Is there a reason template literals are not allowed as property names in object literals? I can do:

let obj = {'foo bar': 1};

and

let obj = {"foo bar": 1};

but not

let obj = {foo bar: 1};

It doesn't seem that allowing the latter would present any syntactic problems and seems like almost an oversight that it's not allowed.

The main reason I ask is that we've gone completely over to using template literals for all our literals (why not?) and was surprised that we can't use a template literal as an object literal property name. Obviously, we can do:

let obj = {[foo bar]: 1};

And given that square brackets allow arbitrary expressions for propery names, it wouldn't seem that supporting template literals for object literal property names would not present any daunting implementation issues.

I guess I'd argue that the Principle of Least Astonishment and/or completeness suggests that JS should support this.

Sorry if this has been asked before but couldn't find anything in the archive.

Thanks

Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 • m: +1 315 527 4764 • w: nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982562151&sdata=mqg7YqYTO6HUqPrqCE1M3NKOtgGAWCf9OOYfTosN0kg%3D&reserved=0

================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982562151&sdata=B69PJqlsl6nBt%2FFpX3j05uo4KR71TT0EDelw5e7at5k%3D&reserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982572144&sdata=fMfK6iYnNZPmtOQiUOeoxSO7w0bpGEb0LdNbPReKFko%3D&reserved=0 Privacy Policy - nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02|01||e77faaad7c8444d9792f08d763c74e54|79544c1eed224879a082b67a9a672aae|0|1|637087579982572144&sdata=I47ddmdxHISIAkZ1Mv%2Fb13jaI2eJRhekdiT7pu4x%2B6Q%3D&reserved=0

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

# Isiah Meadows (4 years ago)

Just wanted to chime in with the fact this has been a thing in CoffeeScript for most (if not all) its existence, as well as with Ruby hash maps, which special-case string keys (you can do {"foo#{bar}baz": whatever}).

Not that I would expect this to have much impact on whether this really minor nice-to-have makes it in, though...

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com