Repository navigation
Missing type-check on explicit cast? #9312
Description
TypeScript Version:
1.8.10
Code
interface Foo {
foo()
bar()
}
// does NOT error:
var a = <Foo> {
foo() {}
// missing bar() - no error!
}
var b = {
foo() {}
// missing bar() - no error!
} as Foo
// errors: (b not assignable to type Foo)
var c: Foo = {
foo() {}
// missing bar() - error
}
function d() : Foo {
return {
foo() {}
// missing bar() - error
}
}In the two first cases, the shape (and inferred type) of the anonymous object are missing a method and clearly are not assignable to Foo - I was expecting an error message.
I don't fully understand why assignment to a var vs assignment to an explicitly typed var or return-type would behave inconsistently in terms of type-checking.
Didn't it use to be that you had to do something like var a = <Foo> <any> { .. }, e.g. you had to explicitly cast the inferred object type/shape to any before you'd be allowed to do an unsafe type-cast?
Activity
RyanCavanaugh commentedon Jun 22, 2016
Enforcing the normal direction of assignability as part of a type assertion would be counterproductive (or at least counterintuitive) -- if it were already assignable, you'd never write the cast in the first place!
The rule is that the expression type and the asserted type must be assignable in one direction or another. This prevents obviously-wrong assertions like
<string>windowwhile still allowing correct-looking assertions like<Horse>someAnimal.There's another issue somewhere I can't find at the moment that talks about having a type assertion operator that changes the type of an expression without performing the bidirectional check. I can probably dig it up if you're interested.
mindplay-dk commentedon Jun 28, 2016
Ryan Cavanaugh (@RyanCavanaugh) that makes sense for something like
<Horse>someAnimal, but probably not so much for an inferredObjectas in my first example? Because practically everything isObjectin one direction or the other.It seems like an exemption might make sense there - because the two first examples are obviously wrong; the inferred type clearly has a shape that is directly incompatible with the type assertion being made, yet they compile without complaint.
At least a warning or notice should be appropriate in that case?
RyanCavanaugh commentedon Jun 28, 2016
Again, this is true of nearly every type assertion. What you're basically proposing is that
be an error because
HTMLElementis missing things fromHTMLDivElement. But that's why you wrote the type assertion in the first place!mindplay-dk commentedon Jun 28, 2016
The compiler can't know precisely what comes out of
getElementById(), or any other method.But in the case where I'm directly casting an object literal, it knows precisely what properties that object literal has; there's no way the assertion in the two first examples could be correct, it's guaranteed to fail.
An object literal with a type-cast is kind of like a construction, and if that object literal is missing any properties, there's no way that results in an object that is valid for that assertion.
Unless I'm missing something?
RyanCavanaugh commentedon Jun 28, 2016
I guess we fundamentally disagree on what a type assertion is used for. My take is, a type assertion is there to let you do things you normally wouldn't be able to do. If you don't want unsafe coercions to take place, don't write a type assertion there! Adding new errors around type assertions that are plausibly correct seems counter to the very goal of a type assertion.
mindplay-dk commentedon Jun 30, 2016
That all makes sense, and I don't think we fundamentally disagree - I'm only talking about the the case where a type-cast is being applied directly to an object literal, because that's kind of like an informal/dynamic constructor, and it's a common JS pattern, constructing something with a known shape but with no formal constructor.
Anyhow, yeah, maybe what I'm describing isn't actually a type-cast at all - maybe it's a different feature altogether, something that shouldn't get mixed up with type-casts... it just felt like the natural thing to reach for, and it was kind of surprising to me when it didn't work - but maybe that's just me ;-)