You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// example.jsvarPerson=function(firstNameOrPojo,lastName){if(typeoffirstNameOrPojo==="string"){this.firstName=firstNameOrPojo;this.lastName=lastName;}else{returnnewPerson(firstNameOrPojo.firstName,firstNameOrPojo.lastName);}};Person.prototype.greet=functiongreet(){return`Hello, I am ${this.firstName}${this.lastName}.`;};varfred=newPerson({firstName: "Fred",lastName: "Flintstone"});console.log(fred.greet());
Expected behavior:
I would expect tsc to compile this code without errors or warnings, especially considering that the returned type always matches the expected type.
In JavaScript, it is possible for a constructor function to return an object. When this is done, the returned object becomes the result of the whole new expression (see step 3 in this MDN documentation for the new operator).
Being concerned with types, I can see why the TypeScript compiler would be hesitant to support this quirk of the JavaScript language. After all, the compiler would have to verify that the value explicitly returned is the same type that would be returned from the constructor had it returned undefined (the usual case). I think this should be supported, because:
TS claims to be a superset of JS.
This is a useful and popular JavaScript technique
The above code runs just fine in Node.js and in the browser:
$ node example.js
Hello, I am Fred Flintstone.
Actual behavior:
tsc issues an error when checking this code:
$ tsc --allowJs --checkJs --outDir ./dist example.js
example.js(8,16): error TS2350: Only a void function can be called with the 'new' keyword.
The text was updated successfully, but these errors were encountered:
kwpeters
changed the title
Support returning values of the expected type from constructor functions
Support returning values from constructor functions
May 19, 2017
The type is actually figured out correctly, regardless what you return; the compiler knows to use the return type when called as a function, and the instance type when used as a constructor. the error is what needs to be addressed for .js file. the pattern is still not allowed for a .ts file (since we error on the conservative side there).
Especially now that we have Proxy, there are nice behaviors that we could implement by returning a proxy instead of the class instance directly. But that won't be possible unless we can infer or specify the return type of the constructor.
if you could put get(target, name) {}
and set(target, name, value) {}
inside the class constructor to override property assignment operators for (any all properties of) Object/Array, then well... javascript wouldn't be falling short.
[Otherwise ya returning the new Proxy with the handler functions would suffice.]
TypeScript Version: 2.3.2
Code
Expected behavior:
I would expect
tsc
to compile this code without errors or warnings, especially considering that the returned type always matches the expected type.In JavaScript, it is possible for a constructor function to return an object. When this is done, the returned object becomes the result of the whole
new
expression (see step 3 in this MDN documentation for the new operator).Being concerned with types, I can see why the TypeScript compiler would be hesitant to support this quirk of the JavaScript language. After all, the compiler would have to verify that the value explicitly returned is the same type that would be returned from the constructor had it returned
undefined
(the usual case). I think this should be supported, because:The above code runs just fine in Node.js and in the browser:
Actual behavior:
tsc
issues an error when checking this code:The text was updated successfully, but these errors were encountered: