Allow property (dotted) access syntax for types with string index signatures

[sandersn]

It doesn't make much sense to forbid property access (o.unknown) syntax on a type with a string index signature, but allow element access syntax (o['unknown']).

Note that this should only apply to types with an explicit string index signature — element access is currently allowed on any type if you don't pass --noImplicitAny, but this should not be true for property access.

Given

type Flags = {
  aLongName: boolean;
  anotherReallyLongOne: number;
  someOtherOnes: boolean;
  [other: string]: number | boolean;
}

Expected behavior:

function f(flags: Flags) {
  flags.aLongName; // ok
  flags.anUnknownName; // ok
  flags.aLongname; // ok, but misspelled
  flags['aLongName']; // ok
  flags['anUnknownName']; // ok
  flags['aLongname']; // ok, but misspelled
}

Actual behavior:

function f(flags: Flags) {
  flags.aLongName; // ok
  flags.anUnknownName; // error, unknown
  flags.aLongname; // error, misspelled
  flags['aLongName']; // ok
  flags['anUnknownName']; // ok
  flags['aLongname']; // ok, but misspelled
}

[jeffreymorlan]

It doesn't make much sense to forbid property access (o.unknown) syntax on a type with a string index signature, but allow element access syntax (o['unknown']).

It makes a lot of sense to me - dotted access is used when the programmer expects the property to have some particular meaning. A map (string-indexed type) is homogeneous, thus the expectation is wrong:

var stuff: { [key: string]: number };

for (var i = 0; i < stuff.length; i++) { // oops, this is nonsense - the "length" property
                                         // doesn't have any special meaning on this object
    console.log(stuff[i]);
}

[gcnew]

I'm strongly against this change. I don't have data for modern JS usage but it used to be that when people used objects as hash tables they preferred indexing access. It might have been because of experience with more rigid languages but I believe the real reason was because it is a different logical use and indexing conveys it to the reader. Also, if this gets merged in we'll lose valuable type checking.

My plea is if you decide to go for it, please add one of your "favourite" flags to turn it off.

Edit: My point is that currently we trade some otherwise valid syntax for additional type safety. And that's good - yes, it is a convention but it is in line with the type signature. On the type level properties are declared naked and the value level counterpart is also naked dot access. Index signatures are declared inside brackets - you access them with brackets.

[mhegazy]

@gcnew, the proposal is only limited to types that have index signatures, and not all types. does this change your feelings about it?

[gcnew]

@mhegazy No. The reason is twofold: objective - we'll lose some static typing (spelling mistakes / refactoring leftovers of "known" properties will no longer be hard checked) and subjective - it incentivises dot access for hashes, which adds burden on the reader.

[bmhaskar]

Good suggestion. Will help in declaring types/interfaces for JSON structure which are received via API's

[ratneshsinghparihar]

Agreed, this proposal make sense.

[aluanhaddad]

TLDR: this is an excellent change. The important thing here is that one should not have to resort to using the any type to access a property.

@jeffreymorlan

It makes a lot of sense to me - dotted access is used when the programmer expects the property to have some particular meaning. A map (string-indexed type) is homogeneous, thus the expectation is wrong:

I vehemently disagree. They are often heterogeneous and that is what makes them useful.
A common example is a dynamic collection of form fields. Each value has an often dramatically different shape from the others, with completely unrelated properties such as options lists, regex validators, function validators, child fields and so on. Using index syntax to access this value has two purposes:

1. To access fields dynamically via external key, for example mapping from a property present in the current shape of the form model into the object to retrieve child fields, options, or validators.
2. To retrieve the value of a statically known key which is a not valid identifier.

When writing JavaScript, I use the indexer syntax only when a key is not valid identifier. This was actually probably the most difficult part of adopting TypeScript for me, I got over at like 4 years ago but it is still annoying. Fundamentally it is far less readable to have to use the string syntax.

@gcnew

I don't have data for modern JS usage but it used to be that when people used objects as hash tables they preferred indexing access.

Even if this is true, I don't see much value in it. It reflects, as you point out, experience with statically typed languages like Java that are unable to express flexible patterns like heterogeneous collections in a typesafe fashion.

Map<string, object> is only homogeneous in the most vacuous sense, it is in fact a static type offering no valuable type safety and a generic instantiation that has no place in a statically typed language that has union types.

it incentivises dot access for hashes, which adds burden on the reader.

I'm not sure what you mean by this. Are you saying that they should be using classes for standard types and ES2015 Maps for everything else? ECMAScript classes are not good enough. They will get better over time, but right now they are very very weak abstraction mechanism. On the other hand maps offer no first class syntax.
As Douglas Crockford said, JavaScript objects are like little hashtables and this is a great thing.

I strongly support this change.

[gcnew]

@aluanhaddad

Are you saying that they should be using classes for standard types and ES2015 Maps for everything else?

No! All I'm saying is that currently MapLikes are obvious and using dotted properties you are 100% safe. This suggestion blurs the line and chips away type safety. I'm a supporter of adding more guarantees, even if it means giving up some otherwise valid syntax.

The following stays the same:

type Coloured<T> = {
    colour: 'red' | 'green' | 'blue',
    value: T
}

declare const c: Coloured<string>;
c.color // Error: typo mistake

However this will change in a negative way:

type WithColour = {
    colour: string,
    [key: string]: string | undefined
}

declare const d: WithColour;
d.color // BAD! Currently an error, will no longer be
d['prop'] // it's obvious we venture into the unknown

d.prop // BAD: Does such a property exist? We'll no longer be sure :(

For me there are two distinct uses of JavaScript objects. One is for structured data - the properties are well know and enumerated in advance. The other is for Maps/Dictionaries/Hashes/you name it. This second one is completely different - we do dynamic lookup based on arbitrary keys for which a value might or might not exist. To be allowed to do this we provide an indexing signature on the type. For me it's only natural to use this very same indexing for access as well. It also conveys the idea that the object is a Map and there is a good chance a corresponding value is not being present.