Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mutable type guards #25679

Closed
4 tasks done
oldrich-s opened this issue Jul 16, 2018 · 6 comments
Closed
4 tasks done

Mutable type guards #25679

oldrich-s opened this issue Jul 16, 2018 · 6 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints

Comments

@oldrich-s
Copy link

oldrich-s commented Jul 16, 2018

Search Terms

mutable type guards

Suggestion

Allow for mutable type guards (i.e. type guards that are always true).

Use Cases

I would like to extend HTMLElements without wrapping them. So basically I would add "extra" property to a HTMLElement that would extend its capabilities.

Examples

function setExtra<T>(el: T): el is T & { extra: { stuff: {} } } {
  (el as any).extra = { stuff: {} }
}

const el = document.createElement('div')
el.extra // type is HTMLDivElement, therefore fail

setExtra(el)

el.extra // type is HTMLDivElement & { extra: { stuff: {} } }, therefore OK

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. new expression-level syntax)
@mhegazy
Copy link
Contributor

mhegazy commented Jul 16, 2018

you can achieve a similar pattern by slightly reordering your code to use immutable objects instead of mutations, e.g.

const el = setExtra(document.createElement('div'));

you can also achieve that using type assertions:

const el = <HTMLDivElement & { extra: { stuff: {} }}> document.createElement('div')

That siad, i do not think we have any plans to model side effects in the type system in the time being.

@mhegazy mhegazy added the Out of Scope This idea sits outside of the TypeScript language design constraints label Jul 16, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@oldrich-s
Copy link
Author

oldrich-s commented Sep 4, 2018

@mhegazy : I have run into the same problem again, this time with Mocha and Chai:

let value: number | undefined

Chai.assert.exists(value)

// value should be now `number` and not `number | undefined`

Chai throws if the value does not exist, therefore after the assert function is called, the value should be of type number.

For now, I have to manually retype values after each assert call, which is really not optimal.

What solution do you propose to this problem?

@RyanCavanaugh
Copy link
Member

See #10421 and its linked issues

@oldrich-s
Copy link
Author

oldrich-s commented Sep 5, 2018

Thank you.

If I am not mistaken, the link you sent discusses block scope type assertions.

What I would like to do is to mutate the type of variables that are sent into a function as function parameters from inside of the function. That would probably break the "block scope" rule discussed in the provided link, right? Then I would have to do

let value: number | undefined

Chai.assert.exists(value)

assume value is number

...

Which is probably not optimal either.

Basically I would like to have type guards without the if statement requirement.

@RyanCavanaugh
Copy link
Member

See also #8655

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints
Projects
None yet
Development

No branches or pull requests

4 participants