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

type guards are not working in this case #1595

Closed
bpasero opened this issue Jan 5, 2015 · 10 comments · Fixed by #1621
Closed

type guards are not working in this case #1595

bpasero opened this issue Jan 5, 2015 · 10 comments · Fixed by #1621
Assignees
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue

Comments

@bpasero
Copy link
Member

bpasero commented Jan 5, 2015

I am using the following example that I took directly from the blog post (http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s-new-in-the-typescript-type-system.aspx)

var x: any = "foo";
if(typeof x === 'string') {
   console.log(x.subtr(1)); // Error, 'subtr' does not exist on 'string'
}
// x is still any here
x.unknown(); // OK

I am not seeing the error or intellisense for the console.log statement.

Are type guards actually supported in this case or only for union types?

@ahejlsberg
Copy link
Member

Type guards do not affect variables of type any. This is a fairly recent change, see #1426 and #1433.

@jonathandturner We should probably update the example in the blog post.

@ahejlsberg ahejlsberg added the By Design Deprecated - use "Working as Intended" or "Design Limitation" instead label Jan 5, 2015
@sophiajt
Copy link
Contributor

sophiajt commented Jan 6, 2015

As per conversation off-line yesterday, I think this should continue to give the more specific type. With simple types like 'string' we have a complete picture of what the user should be able to do in the if-block.

@sophiajt sophiajt removed the By Design Deprecated - use "Working as Intended" or "Design Limitation" instead label Jan 6, 2015
@RyanCavanaugh RyanCavanaugh added Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript Bug A bug in TypeScript and removed Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript labels Jan 7, 2015
@RyanCavanaugh
Copy link
Member

Strong agreement that we should narrow expressions of type any when there is a type guard for a primitive type (typeof x === 'string'), but not in other cases (x instanceof foo).

@ahejlsberg ahejlsberg self-assigned this Jan 8, 2015
@mhegazy mhegazy added this to the TypeScript 1.5 milestone Jan 8, 2015
@ahejlsberg ahejlsberg added the Fixed A PR has been merged for this issue label Jan 8, 2015
@bpasero
Copy link
Member Author

bpasero commented Jan 9, 2015

Thanks!
Am 09.01.2015 00:57 schrieb "Anders Hejlsberg" notifications@github.com:

Closed #1595 #1595 via
#1621 #1621.


Reply to this email directly or view it on GitHub
#1595 (comment).

@bpasero
Copy link
Member Author

bpasero commented Jan 9, 2015

Btw what is the rationale to not also support this in instanceof blocks?

@danquirk
Copy link
Member

#1426 has a specific example of the general class of issues with that case.

@bpasero
Copy link
Member Author

bpasero commented Jan 10, 2015

While I understand this for doing "instanceof Object", I cannot think of a usecase where I do "instanceof MyClass" where I would not want an error to show up when I use a property that does not exist?

@bpasero
Copy link
Member Author

bpasero commented Jan 10, 2015

Also: If I explicitly assign "any" to a type, this is a good indication that I want the type to be any and no errors should show up. But when the type is simply having "any" by default because I did not set a type, you should support type guards.

@sophiajt
Copy link
Contributor

@bpasero - If you're a subclass of MyClass, then instanceof the parent class will be true. This means, we can't say for sure that any property doesn't exist, because it may exist on the subclass.

The net result is that we may error on perfectly valid, and correct, code. We're trying to avoid that with type guards.

@bpasero
Copy link
Member Author

bpasero commented Jan 12, 2015

I disagree. If I check of instance for a super class of my type, I should
not be allowed to use properties of any class that is below that level,
otherwise I would have checked for that class in the first place.
Typescript should be all about discouraging unsafe, untyped access to an
object.
Am 12.01.2015 18:20 schrieb "Jonathan Turner" notifications@github.com:

@bpasero https://github.com/bpasero - If you're a subclass of MyClass,
then instanceof the parent class will be true. This means, we can't say for
sure that any property doesn't exist, because it may exist on the subclass.

The net result is that we may error on perfectly valid, and correct, code.
We're trying to avoid that with type guards.


Reply to this email directly or view it on GitHub
#1595 (comment)
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants