'Discarding Parameters' plus 'Duck Typing' makes every parameter optional? #9352

Activity

1. RyanCavanaugh commented on Jun 24, 2016

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jun 24, 2016

   Member

   More actions

   Your example here is specific to rest parameters, which get special treatment. Note that if you had written this with actually zero arguments, you'd get an error:

   class C1 { one() { } }
   class C2 { one(hi: string) { hi.length; } }
   
   var c1 = new C1();
   var c2 = new C2();
   c1 = c2; // Error

   The reason for this is that many callbacks provide a variable but predictable number of arguments. For example, String#replace will invoke with one argument per matching group in the RegExp, so code like this is very common:

   var r = /(.*)_(.*)_(.*)/;
   var x = 'a_b_c'.replace(r, (str, m1, m2, m3) => { ... });
2. Ryan Cavanaugh (RyanCavanaugh)

   added

   Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed

   on Jun 24, 2016
3. SlurpTheo commented on Jun 27, 2016

   

   SlurpTheo

   on Jun 27, 2016

   Author

   More actions

   Ryan Cavanaugh (@RyanCavanaugh)

   Imagine C1#one actually has code that interacts with the ...hi: string[] rest parameter. As shown, sure the parameter could have just been omitted, but that's a problem with the specific example code I provided -- sorry about that.

   String#replace gives ...args: any[] in the callback function parameter signature; i.e., not too much from a type safety perspective. It feels different to me than the class-based (--noImplicitAny and --strictNullChecks) example I gave.

   If a class method is defined with a single rest parameter, 0 arguments from a CallExpression is perfectly legal. Assigning something to that class method's interface which can accept no less than 1 argument from a CallExpression feels very different than most the static type safety we are usually provided from TypeScript compilation.

   Should methods defined directly on an object/class (maybe even something extra-restrictive/specific to the class keyword here?) have special/extra analysis compared to a function expression, a module function declaration, or class static method declaration? The two examples in this issue-thread which show the usefulness of parameter discarding are for callback function parameters; is it unique to them? Maybe it's just in those cases that function assignment should be more accepting of parameter omissions?
4. RyanCavanaugh commented on Jun 27, 2016

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jun 27, 2016

   Last edited by RyanCavanaugh

   Member

   More actions

   It's a design-trade off in terms of complexity/understandability vs soundness.

   The problem once you start special-casing these rules is that it's immediately unclear where to draw the line. For example, we believe this code to be OK, based on how it's used in the wild (concrete data point: this was illegal in one release of TypeScript and everyone complained about it or was confused)

   declare function invoke<T>(arr: T[], cb: (...args: T[]) => void);
   
   invoke([1, 2, 3], (a, b, c) => a + b + c);

   Now let's say "Oh callbacks are special!". Then we write this code:

   declare function invoke<T>(arr: T[], cb: { success: (...args: T[]) => void; fail?: () => void });
   
   invoke([1, 2, 3], { success: (a, b, c) => a + b + c });

   Maybe that's OK and maybe it isn't? It's not obvious that this is a callback anymore, but from the developer's perspective it's a trivial refactoring. It also breaks the basic symmetry that if T is assignable to U, then { x: T } is assignable to { x: U }, which is terrible in terms of explaining to someone why something happens ("Yes, X is assignable to Y, except if it's wrapped in an object, or is used in a derived class" ==> ❓ 😕 ❓).

   Now we write this code:

   declare class InvokeeBase<T> {
     invoke(...args: T[]): void;
   }
   declare function invoke<T>(arr: T[], cb: InvokeeBase<T>);
   
   class MyInvokee extends InvokeeBase<number> {
     invoke(a: number, b: number, c: number) { ... }
   }
   invoke([1, 2, 3], new MyInvokee());

   Again, it's a basic refactoring of the original code that we thought was totally fine.
5. Mohamed Hegazy (mhegazy)

   closed this as completedon Jun 28, 2016
6. SlurpTheo commented on Jun 15, 2017

   

   SlurpTheo

   on Jun 15, 2017

   Last edited by SlurpTheo

   Author

   More actions

   • https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#strict-contravariance-for-callback-parameters
   • Covariant checking for callback parameters #15104
   • Stricter generic signature checks #16368
   • • --> Contextual generic function types #16305
   • • • --> Infer from generic function return types #16072
   • • • • --> Smarter type inference for functional programming (RxJS, Ramda, etc) #15680
   • Strict function types #18654 (comment)
   • • --> Strict function variance fixes DefinitelyTyped/DefinitelyTyped#20219 (comment)
7. microsoft

   locked and limited conversation to collaborators on Jun 19, 2018