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

Compiler option to disallow assignment of any to a more narrow type #11301

Closed
tcrognon opened this issue Oct 1, 2016 · 11 comments
Closed

Compiler option to disallow assignment of any to a more narrow type #11301

tcrognon opened this issue Oct 1, 2016 · 11 comments
Labels
Needs More Info The issue still hasn't been fully clarified

Comments

@tcrognon
Copy link

tcrognon commented Oct 1, 2016

This currently compiles with no errors:

function deserialize(untrustedData: any): number {
    return untrustedData;
}
const myNum = deserialize('bad data');

If any can only be assigned to any, the compiler can assist in making sure untrusted data is properly type checked. So the example above would have to be changed to

function deserialize(untrustedData: any): number {
    if (typeof untrustedData !== 'number') {
        throw new Error('Not a number.');
    }
    // control flow analysis narrows type to number
    return untrustedData;
}
const myNum = deserialize('bad data');

or

function deserialize(untrustedData: any): number {
    // not recommended, but prevents this new option from being too draconion
    return <number>untrustedData;
}
const myNum = deserialize('bad data');

This is a simplified example, but reflects the frequent task of deserializing untrusted data to typed classes/interfaces where certain types are expected but should be checked.

More generally, it gives the developer confidence that a type really is a certain type in their code in a similar way that the non-nullable option does.

@yortus
Copy link
Contributor

yortus commented Oct 2, 2016

The motivation here looks very similar to #10715.

@RyanCavanaugh RyanCavanaugh added Needs Investigation This issue needs a team member to investigate its status. and removed Needs Investigation This issue needs a team member to investigate its status. labels May 24, 2017
@caseyhoward
Copy link

This also works but shouldn't:

const x: any = 'not a number';
const y: number = x;

@mhegazy
Copy link
Contributor

mhegazy commented Nov 3, 2017

Is this just no-any ?

@mhegazy mhegazy added Needs More Info The issue still hasn't been fully clarified and removed Needs Investigation This issue needs a team member to investigate its status. labels Nov 3, 2017
@caseyhoward
Copy link

No, no-any disallows any's altogether. I want to be able to use any but I don't want it to be assignable to a variable with a concrete type.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 3, 2017

humm.. so what do you do with that any? it has to go somewhere? you never return it from a function, nor send it to another... so only console.log would be allowed? would not it be better to use {} or object in this case?

@caseyhoward
Copy link

You have to validate it. If it's any there is a good chance it's some sort of input from the outside.

function myPublicAddingFunction(x: any, y: any): number {
  if (typeof x === 'number' and typeof y === 'number') {
    // typescript now knows that x and y are numbers
    return x + y;
  } else {
    throw 'numbers only';
  }
}

@mhegazy
Copy link
Contributor

mhegazy commented Nov 6, 2017

u can replace that with number | string | boolean | undefined | null | symbol | object

@mhegazy
Copy link
Contributor

mhegazy commented Nov 6, 2017

or just {} | null | undefined

@caseyhoward
Copy link

Replace what? And how does it fix my issue?

@mhegazy
Copy link
Contributor

mhegazy commented Nov 6, 2017

replace any with {} | null | undefined, then use no-any tslint rule. this will guarantee that there are no unsafe assignments to any.

@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.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs More Info The issue still hasn't been fully clarified
Projects
None yet
Development

No branches or pull requests

6 participants