Inconsistent conditional type results between interfaces and inline types when matching against an index type signature

[greyepoxy]

TypeScript Version: 3.0.0-dev.20180522

Search Terms: Index, Conditional, Signature

Code

type IndexSignatureType<T> = T extends { [key: string]: infer R } ? R : never;

interface TestInterface {propWithString: string; propWithNumber: number }

type testWithInterface = IndexSignatureType<TestInterface>;
// type testWithInterface = never

type testWithInlineType = IndexSignatureType<{ propWithString: string; propWithNumber: number }>;
// type testWithInlineType = string | number

Expected behavior:
Both testWithInterface and testWithInlineType should report that they are of the never type

Actual behavior:
testWithInterface reports it is of the never type but testWithInlineType reports that it is a union of its possible props

Playground Link:
link

Related Issues:
There seemed to be several issues related to index signatures. Not sure if they are really related or not... for example #23226 and #23994

Context:
I am working on an any object validation library, where a user provides an interface as a generic to a function and then has to provide an object with "validation functions" for each property in the given interface. The code then uses this property to validation function object to validate that an arbitrary object looks like the given interface. Works great until index signature types get involved. That lead me to using the described IndexSignatureType conditional generic type above to figure out if a given interface/type had an index signature type as part of its definition or not. My plan was to use this type definition as a mechanism for forcing the user to use a different function in this case where they just provide a single validation function for all of the object props. With the above inconsistencies in the conditional types this does not work.
Some examples of what I am talking about,

import * as validate from 'ts-any-validator'; // my library, not published though sorry...

interface TestInterface {
  propWithString: string;
  propWithNumber: number;
}

const validateIsTestInterface = validate.isObjectWithKnownProps<TestInterface>({
  propWithString: validate.isString,
  propWithNumber: validate.isNumber,
});
// This this an example usage which throws an error if validation for any of the properties fails
validateIsTestInterface({ propWithString: '', propWithNumber: 10 });

// Using a mechanism similar to the one described above neither of these works, which is great!
// In both cases below there is an error because the param resolves to a never (exactly what I want)
interface AnotherTestInterface {
  [key: string]: string;
}
const validateIsAnotherTestInterface = validate.isObjectWithKnownProps<AnotherTestInterface>({}); // expected error Argument is not assignable to 'never'

const validateIsLikeAnotherTestInterface = validate.isObjectWithKnownProps<{
  [key: string]: string;
}>({}); // expected error Argument is not assignable to 'never'

// Instead of using `isObjectWithKnownProps` for types with signature types a different function is used
// no error in this case
const validateIndexSignatureType = validate.isObjectWithIndexSignature<AnotherTestInterface>(validate.isString);


// But this one should not resolve to a never and does because of this issue described above
const validateHasProp = validate.isObjectWithKnownProps<{
  prop: string;
}>({}); // unexpected error Argument is not assignable to 'never'

Hopefully the context makes some sense...

Thank you for all your hard work!

FYI @mjbvz

[mhegazy]

Duplicate of #15300

[greyepoxy]

@mhegazy
Yeah this does seem related to that but looks like I am asking for something different then folks in that thread.

From what I can tell folks in that issue are asking for "Things that look like { [key: string]: string; } should be assignable/castable to that type." Today you can do that with types but not with interfaces.
That seems to explain the inconsistency I am calling out here.

I guess what I am really asking for is "How can I conditionally match on a type/interface that has an explicit type index signature." My guess is that if #15300 is resolved its going to mean in my above example both testWithInterface and testWithInlineType resolve to string | number which is the opposite of what I was hoping for.

hmm is this a feature request then?

[mhegazy]

Type literals have an implicit index signatures. interfaces do not. that is the current design. see #15300 (comment) for more details. #15300 tracks addressing the discrepancy.. do not know which way it would go.

There is no way to distinguish between an implicit index signature, and an implicit one. and again this is by design.

[greyepoxy]

okay closing this out then, might or might not open a feature request for conditionally matching support against an explicit index signature.