Suggestion: a way to disable type widening in object literals

[pelotom]

I understand the use of type widening with let and var variables (I use const ubiquitously so this is never a problem). But with object literals I pretty much never want the fields to be widened, and yet that's the default behavior:

const o = { x: 3 }; // inferred type is { x: number }

The only way I know of to work around this is with casts or type annotations, or by passing the object literal immediately to a function expecting the narrower type, thereby guiding type inference (although if the literal is being returned from a function even that technique won't work).

This is an eternal headache and it crops up in so many places. Would it be possible to add a compiler flag that makes it so that object literals don't get widened? I'm happy to be responsible for adding type annotations in the extremely rare cases where I actually want the widened type.

Edit

It looks like compiler flags are generally frowned upon to solve this problem, so let me amend my suggestion to take account of the discussion below. @mhegazy says,

We have talked in the past about a readonly modifier on property declarations.. e.g.

const o = { readonly x: 3 }; 

this allows the compiler to understand the intent of this object literal property, and not widen.

This would certainly be handy, but on its own it's still not ideal because one ends up writing readonly in a lot of places. Take for example CSS-in-JS objects, which involve many properties whose types are unions of string literals. Every single one of those properties needs to then be marked readonly in order to defeat the scourge of type widening. But if one could declare an entire object literal to have only read-only properties like so:

const o = readonly { x: 3, y: 'hello' };
// o: { readonly x: 3; readonly y: 'hello' }

now this starts to look like a workable solution! So, let this be my amended suggestion: readonly modifiers for both object literal properties as well as object literals themselves, which has the side effect of disabling type widening.

To the argument that readonly and type-widening are separate concerns and should be treated independently, to some extent I agree, but I also feel they are related; this is why the let vs. const rules for type widening exist, and I think that rationale makes sense. I also personally don't mind conflating readonly and type narrowing, because I prefer immutable objects everywhere too, so a syntax like

const o = readonly { x: 3, y: 'hello' };

would be attractive because it kills 2 birds with one stone. I currently don't use the readonly keyword much (even though in spirit I want everything to be read-only) because the cost-benefit ratio of annotating every single property in every single object literal is too high.

[mhegazy]

We have talked in the past about a readonly modifier on property declarations.. e.g.

const o = { readonly x: 3 }; 

this allows the compiler to understand the intent of this object literal property, and not widen.

[zpdDG4gta8XKpMCd]

works today:

const o = new class { readonly x = 3 }

[mhegazy]

I do not think the flag is right thing to do. such behaviors should not controlled by flags. The flags we have that alter the behavior are meant to be transitional, in other words, we would like everyone to turn them on, but acknowledge the need for a migration path. In this case, i am not convinced that constdeclaration should mean that all the properties, however deep they are are immutable.. that is not the spec'ed behavior of const, nor what the compiler asserts.

[pelotom]

@mhegazy that's still less than ideal, because in the limit it requires writing readonly many many times when what I really want is just a blanket statement across my entire code base.

[pelotom]

If readonly could used as a modifier of object literals to make all their properties readonly, I think that would be usable:

const o = readonly { x: 3, y: 'hello' };
// o: { readonly x: 3; readonly y: 'hello' }

Or if it were possible to write a function makeReadonly that could do the same

const o = makeReadonly({ x: 3, y: 'hello' });
// o: { readonly x: 3; readonly y: 'hello' }

[zpdDG4gta8XKpMCd]

@pelotom you should make it clear of what exactly you expect when you say readonly x: 3, because one thing is to have the type 3 another thing is making x property readonly

reading/writing is orthogonal to widening/narrowing

it's by accident that readonly modifier makes the property type narrowed to the type of the value used for initializing

[pelotom]

@Aleksey-Bykov I agree, my concern here is with disabling type widening, and readonly was @mhegazy's proposed means to that end. If there's another way to disable type widening that doesn't require me to use a keyword for every property in an object literal, I'm all for it.

[zpdDG4gta8XKpMCd]

also consider this

const x = 3;
const o = { x };

[zpdDG4gta8XKpMCd]

because

const x = 3, y = 'a', z = null;
const o = { x, y, z };

is arguably more typing than

const o =  {
    readonly x: 3,
    readonly y: 'a',
    readonly z: null
}

[pelotom]

Also I should add that I personally don't mind conflating readonly and type narrowing, because I also prefer immutable objects everywhere, so a syntax like

const o = readonly { x: 3, y: 'hello' };

would be attractive because it kills 2 birds with one stone. I currently don't use the readonly keyword much (even though in spirit I want everything to be read-only) because the cost-benefit ratio of annotating every single property in every single object literal is too high.

[zpdDG4gta8XKpMCd]

be aware there was a discussion on literal literals (no puns): #10195

[pelotom]

@Aleksey-Bykov I appreciate all of your proposed work-arounds; believe me when I say that I'm already making heavy use of such things, and find them unsatisfactory. This issue is for proposing an augmentation of the language which would make such workarounds unnecessary.

[zpdDG4gta8XKpMCd]

i hear you, first class support would be ideal, i am convinced that literal type literals is the way forward