Suggestion: a way to disable type widening in object literals

Mohamed Hegazy (@mhegazy)

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. Mohamed Hegazy (@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.

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.

works today:

const o = new class { readonly x = 3 }

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.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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.

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' }

Tom Crockett (@pelotom)

Tom Crockett (@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

Aleksey-Bykov

Aleksey-Bykov I agree, my concern here is with disabling type widening, and readonly was Mohamed Hegazy (@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.

also consider this

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

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
}

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.

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

Aleksey-Bykov

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.

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

What about a compiler option to make all declared objects readonly by default (with a type flag mutable to undo that)? Would be useful for React+redux I think. As everything is readonly there - props, states, stores etc.

dmitrysteblyuk

dmitrysteblyuk #17785 (comment)

@tycho01 well, that's not what I meant. Currently objects properties are mutable by default and we have readonly modifier to change that. I suggested to have a compiler option to kinda reverse that behaviour - objects properties (and arrays) readonly by default, mutable if specified so directly in type declaration.

We understand your proposal. The comment still applies. The proposal is neither a temporary patch for a breaking change in behavior (since mutable-by-default is the prefered way to go), nor a “stricter behaviors that we think users should move to”. That means it's a no-go for the maintainers of TypeScript.

m93a

m93a

since mutable-by-default is the prefered way to go

Preferred by whom? The absolutely major part of code in React projects forbids mutating anything. Angular also doesn't do well with mutability (since it checks only object references changes now). So why do you think it's not stricter behaviours that users should move to?

heck, any static typing system doesn't do well with mutation.

So why do you think it's not stricter behaviours that users should move to?

for the record, I do, but they're stuck with all types of JS users ("any valid JS is valid TS!") and don't want their language to bifurcate. let's hope Wasm will save us from this.
that said, I think the Flow guys are pretty big on FP, though it wouldn't help Angular.

This continues to be a huge stumbling block for people trying to learn the language:

https://twitter.com/kentcdodds/status/1081333326290415618

(As well as an annoyance for those who understand what’s going on!)

I've been googling for the right issue for a while. Hopefully this is it.

A variation of the main issue is when the value is provided directly.

For example:

function createAction<TType>(type: TType) {
    return {
        type: type
    };
}

const doStuff = createAction("DO_STUFF")

Ignoring the question about the return of the function createAction, the main problem in this example is that createAction sees the coming argument as a string, not as the string literal type "DO_STUFF".

The main characteristic of this example is that the string is defined in-place where it's passed directly to the function.

There are workarounds, like createAction<"DO_STUFF">("DO_STUFF") or createAction("DO_STUFF" as "DO_STUFF"), or even const type = "DO_STUFF"; createAction(type);, but these are ugly to require in a public API.

This is inspired by this tweet which is about Redux Starter Kit.

Definitely a common problem. As a workaround, I sometimes use as to narrow the type back to the intended constant. It's definitely not ideal:

// inferred {type: 'potatoes'}
const foo = {type: 'potatoes' as 'potatoes'};

// inferred {type: string}
const bar = {type: 'potatoes'};

Works with e.g. as 3 or as true as well.

Also a weird case:

const a = 0 // a: 0
const b = {readonly a} // b: {readonly a: number}

😕

Everyone continuing to comment on this issue should check out #29510.

Navigation Menu

Repository navigation

Suggestion: a way to disable type widening in object literals #20195

Edit

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggestion: a way to disable type widening in object literals #20195

Description

Edit

Activity

mhegazy commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

mhegazy commented on Nov 21, 2017

pelotom commented on Nov 21, 2017

pelotom commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

pelotom commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

pelotom commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

pelotom commented on Nov 21, 2017

zpdDG4gta8XKpMCd commented on Nov 21, 2017

17 remaining items

dmitrysteblyuk commented on Oct 18, 2018

KiaraGrouwstra commented on Oct 18, 2018

dmitrysteblyuk commented on Oct 19, 2018

cshaa commented on Oct 19, 2018

dmitrysteblyuk commented on Oct 19, 2018

KiaraGrouwstra commented on Oct 20, 2018

pelotom commented on Jan 5, 2019

Meligy commented on Jan 21, 2019

stepanhruda commented on Jan 22, 2019

qm3ster commented on Jan 22, 2019

pelotom commented on Jan 23, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions