Computed properties (but not known symbols)

[JsonFreeman]

ES6 allows an arbitrary expression as the name of a property. The syntax is like this:

var x = {
   ["some" + "arbitrary" + "name"]: 0
}

Here is my current proposal for supporting this feature:

Computed expressions would be allowed in the following places if target is ES6:

• Object literal properties
• Class methods and accessors (both static and instance), but not property declarations.
• 'this' references are not allowed in computed properties.
• No parameter properties
• Do not allow in interfaces
• No enum members

Below ES6:

• Computed properties are not allowed

Note that emit for all of the above is straightforward.

Type check:

• All computed names must be of type string, number, or any (or eventually symbol)
• No property will be added to the containing type based on a computed name.
• Computed names that are not well known do not add a property to the type, but they will be included in the union type for the indexer, if the containing type has an indexer.

Questions:

• Should an unknown name cause the surrounding type to have an indexer, if it wouldn't have acquired one otherwise? Our decision here is 'no'. Here is an argument for and against:

Argument for - we would want this to work:

var n = "some " + "unknown " + "name";
var obj = {
    [n]: 0;
};
var num = obj[n]; // This should be number

Argument against - Computed properties would be allowed in class properties, so someone might have a class hierarchy like this:

var n = "some " + "unknown " + "name";
class C {
    [n]: number;
}
class D extends C {
   foo: string; // Error because C was given an implicit indexer that D inherited, but foo doesn't conform to the indexer
}

[JsonFreeman]

containing type

[ahejlsberg]

Can you give an example of when this would happen?

[JsonFreeman]

Yes, a good example is tests\cases\conformance\es6\computedProperties\computedPropertyNames32.ts:

function foo<T>() { return '' }
class C<T> {
    [foo<T>()]() { }
}

I will add this snippet in a comment in the code as well.

[DanielRosenwasser]

So ensure that either it does not have a computed name OR if it does, it has a symbol? I'm confused.

[JsonFreeman]

OR that it has no name!

[JsonFreeman]

Would it be better to invent a term for this, and put a doc comment above the function that defines the term? I could call it a dynamic name

[DanielRosenwasser]

We should discuss this; @yuit and I think that the "But" is a problem - it's just "And" but it indicates something that is contradictory in intuition.

hasDynamicName is not bad for starters

[JsonFreeman]

Ok, I will change that. You're right, "but" is bad.