This project is read-only.

Function signature in interface not respected, but no compiler error

Topics: General
Aug 17, 2013 at 12:01 PM
interface A {
    foo(x: string): void;

var k: A = {
    foo(): void {
There should be an error stating that does not conform to the interface specification, yet the compiler has no problem with the code as-is. TypeScript 0.9.1.
Aug 17, 2013 at 3:44 PM
Actually I just realised that this behaviour is by design. Would be interested in a way of annotating that the method needs to be implemented exactly, not loosely.
Aug 18, 2013 at 12:43 PM
Yes, I also think that there should be some kind of "strik" (like no implicit any) mode, where interfaces should be implemented exactly, because in 95% this is what you want. It also makes refactoring much easier...
Aug 19, 2013 at 5:37 AM
Edited Aug 19, 2013 at 5:37 AM
I wanna add that the way it is implemented at the moment it means that you aren't saved from typos at the callsite in many cases (that I constantly run into) which in my opinion kinda defeats the purpose of the entire interface.

The example is somewhat contrived but I have run into this problem a few times:

Note that firstName is misspelled as fristName at the callsite, however since the interface doesn't limit what can be assigned and firstName is optional it is not regarded as an error.

I agree that there should be a flag for this, or maybe a keyword like 'strict interface' or something to bring in the functionality that only things defined in the interface are permissable at the callsite.
Sep 24, 2013 at 10:03 AM
Yes, a very common pattern for libraries is to initialize a resource using an Object literal. By doing this you can check that if you use the right attribute but with the wrong value for example httpOptions = {port: '1234'} would be an error because '1234' is a string. However we can't show an error for the case where the user does something like httpOptions = {poort: 1234}.

Conclusion: A "strict interface" would be nice. Only keys named in the interface are allowed.
Dec 16, 2013 at 3:41 PM
The code in NathanRidley's post from August now causes a compiler error in VS with 0.9.5, but it seems to work from the command-line and in the playground. Are you seeing that too?

Error 1 Debug Failure. False expression: Provided ast is not the expected AST, Expected: ObjectLiteralExpression Given: FunctionPropertyAssignment C:\Users\Steve\Documents\Visual Studio 2013\Projects\TypeScriptHTMLApp1\TypeScriptHTMLApp1\VSTSC TypeScriptHTMLApp1
Dec 16, 2013 at 11:49 PM
That is what happens with an 0.9.5 build for me as well. It's fixed in our more recent bits.

As far as this behavior goes, it's simply modeling existing JavaScript semantics. Consider that even with a compiler error it's not really enforcing all that much. That is, even if your implementation in k required a string argument there's nothing requiring that the value be used when foo is called. In some sense it's actually clearer here that the implementation of foo is stating its intention to not use the passed in value.