How to define a parameter as optional, but if specified be ensured as not undefined.

[electricessence]

This is a bit tough to explain but probably similar to: #10014

TypeScript Version: 2.0.6

Code

So if I want to specify (when using strict null checks):

export interface Selector<TSource, TResult>
{
	(source:TSource, index?:number):TResult;
}

Which will allow me to use functions that take 1 or 2 parameters where the second one is a number or undefined. But what I really want is that if a second parameter is defined it will be a number.

Any signature style overrides I tried seemed to just screw things up more.
Is there a workaround for this without having to create separate interfaces like:

export interface Selector<TSource, TResult>
{
	(source:TSource, index?:number):TResult;
}
export interface SelectorIndexed<TSource, TResult>
{
	(source:TSource, index:number):TResult;
}

[RyanCavanaugh]

There isn't a way to specify that a parameter is optional but may not accept undefined. Basically, TypeScript's view of the world is that the only legitimate way to resolve overloads is by checking for undefined, rather than checking arguments.length, and that applies symmetrically to callers (you can pass undefined any time you could have omitted a parameter).

[electricessence]

There seems to be other ways of solving this but it seems like extra work (like in my sample).

Here's an example of how I ran into this and what I had to do to get around it...
(Obviously with strictNullChecks:true)

// Given the following map function...  And the Selector as described above.
function map<T,TResult>(source:T[], s:Selector<T,TResult>):TResult[] {
  var result:TResult[] = [];
  for(let i = 0; i<source.length; i++) {
     let e = source[i];
     result[i] = s(e,i);
  }
  return result;
}

console.log(map(["a","b","c"], (e,i)=>i)); // [0,1,2]

The problem I encountered is when you use (e,i)=>i strictNullChecks will emit an error that i could be undefined. Now I understand it's as easy as writing: (e,i)=>i! and you're done. But I thought a lot about this and it's just not right... I should be able to say with absolute confidence that i _will_ return a number. The other conundrum happens if I try to enforce it in reverse because what if the lambda I wrote is simply e=>e+"x" then i is unneeded and will break even though it's just extra.

The only solution I came up with (which is okay, but not ideal) is adding an overload to this example map method:

function map<T,TResult>(source:T[], s:(e:T,i:number)=>TResult):TResult[]
function map<T,TResult>(source:T[], s:Selector<T,TResult>):TResult[]
{
///....
}

And to be honest I'm not 100% sure if the above code works. Actual implementation (of what I did) is here:
https://github.com/electricessence/TypeScript.NET/blob/master/source/System/Text/RegularExpressions.ts#L195-L209
Where MatchEvaluator is simply a Selector.

[RyanCavanaugh]

Callback parameters (e.g. index in your Selector / map example) should not be defined as optional -- that's why you're getting the error about undefined there. Optional in that location means "I may or may not provide this to you", not "You don't necessarily have to look at that parameter".

[electricessence]

Right... That actually makes sense. I think on a fundamental level you are correct. The issue is the amount of additional code required to get it to work that way. So this comes back to (please help me if I'm doing this wrong):

Why can't I:

export interface Selector<TSource, TResult>
{
    (source:TSource):TResult;
    (source:TSource, index:number):TResult;
}

When I do the above, I encounter a huge amount of breakage.
The question is... Am I writing this overloaded signature correctly?
Is this the correct way?

[electricessence]

And so more importantly... I'm pretty confident I can get the above to work... BUT...
It means much more complicated signatures for parameters in functions. :(

[electricessence]

Okay so here's the problem I'm seeing with the above signature...
All my lambdas using it report:

Error:(1022, 13) TS7006: Parameter 'x' implicitly has an 'any' type.

Which they didn't have any problem inferring the type of x before. :(

[electricessence]

So it keeps falling back to (as you were saying) being more constrained (not optional parameters) but that I have to define multiple signatures for every method that takes a selector.

[electricessence]

One last question:
How do signatures decide which are valid? Do you have to always have a root signature?

a(v:Number) {}
a(v:String) {}
a(v:Number | String) {}

// older way:
b(v:Number) {}
b(v:String) {}
b(v:any) {}

But in the case of 'b' you aren't allowed to pass boolean even though the root is 'any'. :/

In the case I'm talking about... Why is this allowed:

a(s:Selector<T,TResult>) {} // where Selector does not contain an index parameter.
a(s:SelectorWithIndex<T,TResult>) {} 

...update...
Okay so it seems that to get this to work the way I want, I need to do this:

a(s:Selector<T,TResult>|SelectorWithIndex<T,TResult>) {}
a(s:SelectorWithIndex<T,TResult>) {} 

[RyanCavanaugh]

Please take questions to Stack Overflow. I think you also need to refer to this FAQ entry: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-am-i-getting-supplied-parameters-do-not-match-any-signature-error regarding signatures, and also remember not to use Number or String (you almost always want to use number or string)

In general if you have a callback type, it should only have one signature, and you should specify the full arity of that signature.

If you have a function type, write as few signatures as possible (i.e. combine individual types into union types), and place more-specific signatures (those taking more arguments or more-specific types) before less-specific signatures.

[electricessence]

Sorry if I'm over asking. It still seems like something that needs fixing. I have to write a lot more to get the result I'm expecting.. Including (update) needing to do this:

a(s:Selector<T,TResult>) {}
a(s:SelectorWithIndex<T,TResult>) {} 
a(s:SelectorWithIndex<T,TResult>) {} 

[electricessence]

I'm guessing that answers my question. It has to have a root signature. :/

[RyanCavanaugh]

This is very confusing because you're not even posting legal syntax. Self-contained examples, that actually parse, with what you expect to happen, would be really useful.

[electricessence]

I working on a solution and will post it and close this issue once I do (shortly).
Any subsequent suggestion/comments will be appreciated.