IssueRaiser

'identity' modifier to indicate a function's parameter-less returns should be narrowed like a value

### πŸ” Search Terms indicate function returns identical value cached memoized signals ### βœ… Viability Checklist - [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code - [x] This wouldn't change the runtime behavior of existing JavaScript code - [x] This could be implemented without emitting different JS based on the types of the expressions - [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.) - [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types - [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ### ⭐ Suggestion Many apps today are built on the concept of using small "getter" functions as wrappers around values. For example, _Signals_ as implemented in [Angular](https://angular.dev/guide/signals "Angular Signals"), [Solid](https://docs.solidjs.com/concepts/signals "Solid Signals"), and the stage 1 [TC39 Signals proposal](https://github.com/tc39/proposal-signals) often look something like: ```ts declare const value: () => string | undefined; if (value() !== undefined) { console.log(value().toUpperCase()); } ``` Signals users have struggled with using them in TypeScript because, at present, there isn't a way to get that code block to type check without type errors. Signals users know that the result of `value(

Posted by JoshuaKGoldberg on Jan 10, 2025, 12:54 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments

github (Software)

'identity' modifier to indicate a function's parameter-less returns should be narrowed like a value

JoshuaKGoldbergJan 10, 2025, 12:54 PM

### πŸ” Search Terms indicate function returns identical value cached memoized signals ### βœ… Viability Checklist - [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code - [x] This wouldn't change the runtime behavior of existing JavaScript code - [x] This could be implemented without emitting different JS based on the types of the expressions - [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.) - [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types - [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ### ⭐ Suggestion Many apps today are built on the concept of using small "getter" functions as wrappers around values. For example, _Signals_ as implemented in [Angular](https://angular.dev/guide/signals "Angular Signals"), [Solid](https://docs.solidjs.com/concepts/signals "Solid Signals"), and the stage 1 [TC39 Signals proposal](https://github.com/tc39/proposal-signals) often look something like: ```ts declare const value: () => string | undefined; if (value() !== undefined) { console.log(value().toUpperCase()); } ``` Signals users have struggled with using them in TypeScript because, at present, there isn't a way to get that code block to type check without type errors. Signals users know that the result of `value(

Comments (0)

No comments yet. Start the discussion.

Comment on this issue