microsoft / microsoft/TypeScript

Request: support old ES "with" statement

Open
#41,051 17 comments 21 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Awaiting More Feedback Suggestion
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

I did not thoroughly search for this!
I'm sorry, it's pretty hard to search for such a common word, there were thousands of issues that use "with," but I tried looking through the first few hundred.

Suggestion

TypeScript support (a restricted subset of) the old JavaScript keyword: "with."

Use Cases

Simplifies code that accesses a large number of different, yet known keys of an object in quick succession.

Examples

const foo = {
    bar: "baz",
    qux: "foobar"
};

with ( foo ) {
    // introduces two new variables into scope
    // bar :: string
    // qux :: string
    console.log(bar, qux);
}
// bar : not in scope
// qux : not in scope

output:

const foo = {
    bar: "baz",
    qux: "foobar"
};

{
    console.log(foo.bar, foo.qux);
}

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

~ This is a runtime feature, but this is already a feature that was implemented in ECMAScript itself (at some point).
Technically, it has not been removed. It is merely disallowed in strict mode.

I do not recommend supporting the actual ECMAScript "with" statement (I hate that the self/window/globalThis object is still global).
Instead, I suggest that a very restricted subset is supported.

It would have to be very restrictive in order to not bring back the problems of the original "with."
Suggested restrictions to ensure code can still be typed and remain safe:

  • The object may only have known keys (string literals, no symbols, no numbers), it may not be an array.
  • The object must be contained in a variable, specifically one that is const (function calls can mutate non-const variables).
    (The variable restriction may be alleviated if the code is transpiled into a block with a variable assignment.)
  • (should not be done at global scope?)

It is very possible to transpile with to perfectly safe runtime code that can be guaranteed to be as safe as if one had explicitly accessed the object.
It wouldn't be hard if only supporting a subset, yet there are other implications to consider, such as performance, especially with nested with statements.

(And yes, this could also be used to create the most hellish spaghetti code you have ever seen.)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or compiler entry points are named. Start by reviewing the TypeScript Design Goals and the proposed restrictions, then determine whether the type-checking and JavaScript-emission implications have a settled design. Done would require an agreed scope before implementation can be evaluated.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
24/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.