Intellisense 등을 사용하여 VS Code에서 이것을 사용하는 빠른 방법을 원하는 사람을 위해 여기에 놀이터 repo 가 있습니다.

유형 P = foo(0) 유형; // P는 임의[]
유형 Q = foo 유형(true); // Q는 문자열입니다.

값 대신 유형을 인수로 사용하는 것이 더 유효한 구문이라고 생각합니다.

type P = typeof foo(number);    // P is any[]
type Q = typeof foo(boolean); // Q is string

값이 아닌 유형을 인수로 제공하기 때문에 함수가 호출되지 않는다는 것이 더 분명합니다. 다른 점은 덜 모호하다는 것입니다. 어떤 사람들은 typeof foo(false) 를 사용하고 어떤 사람들은 typeof foo(true) 를 사용합니다. 유형이 인수로 있는 경우 사람들은 typeof foo(boolean) 만 쓸 수 있습니다.

@tinganho 정확히!
여전히 #5185로 typeof foo("abc") 를 쓸 수 있지만
여기서 "abc" 는 싱글톤 문자열 유형입니다.

@tinganho 나는 당신의 아이디어에 대해 약간의 생각을 해보았고 이 제안에 대해 내가 선호하는 것과 당신의 제안에 대해 선호하는 다른 것을 보았습니다. 귀하의 제안은 귀하가 제공한 이유 때문에 좋습니다(더 간단하고 명확한 구문, 덜 모호하고 함수 호출처럼 보이지 않음). 내 제안에 대해 선호하는 점은 새로운 구문을 도입하지 않아 파서/검사기에 복잡성을 추가하지 않으며 인수에 대한 간단한 유형 이름이 없는 더 복잡한 시나리오도 지원한다는 것입니다.

foo(number) 구문과 같은 것을 작성하는 매우 간단한 방법이 있지만 기존 표현식 구문 분석 메커니즘을 사용하면 어떻게 될까요? 그래서 실험으로 _unary as_라는 새로운 표현을 도입했습니다. as T (null as T) 약어입니다. 당신은 기본적으로 _'나는 값에 대해 신경 쓰지 않지만 표현식이 X 유형을 갖기를 원합니다'라고 말하고 있습니다.

이 변경 사항( Playground repo 에서 구현함)을 사용하면 제안된 구문에 훨씬 더 가까운 것을 작성할 수 있지만 여전히 일반 표현식으로 구문 분석됩니다.

type P = typeof foo(as number);    // P is any[]
type Q = typeof foo(as boolean); // Q is string

let prop2: typeof (as MyInterface).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

이것은 단지 빠른 실험이었습니다. 동등한 구문은 다음과 같을 수 있습니다(하지만 구현하지는 않았습니다).

type P = typeof foo(<number>);    // P is any[]
type Q = typeof foo(<boolean>); // Q is string

let prop2: typeof (<MyInterface>).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

두 번째 구문은 (<T> null) 의 약어인 <T> 표현식을 사용하여 _nullary 유형 assertion_이라고 할 수 있습니다.

@yortus , 우리는 지난 주에 이 제안에 대해 이야기하는 데 시간을 보냈습니다. 더 일찍 게시하지 못해 죄송합니다. 합의는 1이었습니다. 일부 유형을 참조할 수 없는 문제가 있습니다. 예를 들어 함수의 반환 또는 클래스 표현식의 인스턴스 유형이 있습니다. 2. 유형 위치에 표현식을 추가하는 것은 우리가 편한 일이 아닙니다.

@tinganho 의 제안도 우리가 이야기한 것 중 하나였습니다. 구현하기가 더 복잡할 수 있지만 더 맛있을 것이라고 생각합니다. 새로운 단항 연산자를 추가하거나 캐스트 구문을 사용하는 것은 유형 이름을 사용하는 것만큼 우아하지 않습니다.

오늘 슬로그에서 꽤 오랫동안 토론했습니다. 여기에서 "PR 수락"은 "구현이 너무 미친 것으로 판명되지 않는다는 가정하에 PR 수락"입니다.

@tinganho 의 제안은 (적어도 다른 옵션에 비해) 꽤 좋아 보이며 이것을 구현하는 잠정적 PR을 보고 싶습니다.

까다로운 점은 f(number) 대 f(0) 의 반환 유형을 해결하기 위해 완전히 별도의 코드 경로를 갖고 싶지 않다는 것입니다. 그러나 과부하 해결 알고리즘은 _types_ 세트가 아닌 _expressions_ 세트로 작업하고 있습니다. 그러나 우리는 약간의 속임수로 이것이 간단해야 한다고 생각합니다.

기본 공격 계획은 다음과 같습니다.

• typeof 구문 분석 시 문법을 확장하여 함수 호출, 속성 액세스 및 인덱싱된 속성 액세스와 같은 것을 허용합니다.
• 형식 쿼리에서 함수 호출에 대한 인수를 구문 분석할 때(이를 _psuedocalls_ / _psuedoarguments_라고 합시다) parseType 함수를 사용합니다. 이것은 TypeNode 를 생성하지만, 유형 쿼리의 컨텍스트에서 구문 분석된 유형임을 나타내는 플래그를 노드에 설정합니다.
• 검사기에서 checkExpression 는 이 플래그를 확인하고 일반 표현식 처리 대신 getTypeFromTypeNode 를 호출합니다.

@mhegazy , @RyanCavanaugh 팀이 얼마나 많은 코너 케이스를 논의했는지 잘 모르겠는데, 설명을 위해 여기에 몇 가지를 가져와도 될까요? 아래에 여러 예제를 나열하고 typeof 작업의 결과라고 생각하는 것으로 각 예제에 주석을 달았으며 의심스러운 경우에는 물음표를 표시했습니다.

인덱서 표기법

var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number or ERROR?
type Elem3 = typeof data[1+2];      // ERROR or number?
type Elem4 = typeof data[LOBOUND];  // ERROR or number?

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number or number|string?
type Elem5 = typeof tuple[1];       // string or number|string?
type Elem6 = typeof tuple[999999];  // number|string or ERROR?

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // ERROR or number or any?

함수 반환 유형 표기법

// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // ERROR or string[]?

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // ambiguous? or picks first overload?
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // ambiguous? or picks first overload?
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // ambiguous? or picks first overload?

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

클래스/인터페이스 유형의 일부 추출

즉, 위의 typeof (<MyInterface> null).prop1.big.complex; 예제입니다.

나는 이것이 범위를 벗어나 지원되지 않을 것이라는 위의 의견에서 가져옵니다. 그 맞습니까?

인덱서 표기법

var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number
type Elem3 = typeof data[1+2];      // ERROR, only literals allowed here
type Elem4 = typeof data[LOBOUND];  // number when const resolution is done, otherwise any

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number
type Elem5 = typeof tuple[1];       // string 
type Elem6 = typeof tuple[999999];  // number|string

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // number when const resolution work is done, otherwise any

함수 반환 유형 표기법

// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // error, 0 is not a type

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // picks first overload
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // picks first overload
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // picks first overload

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

여기서 무슨 일이 일어나는지 궁금합니다.

const number = "number";
type Ret3 = typeof f2(number); // What happens here?

@SaschaNaz 좋은 질문입니다. 비슷한 상황:

class MyClass { foo; bar; }
declare function f(inst: MyClass): number;
type Ret = typeof f(MyClass);     // number (presumably)

이 경우 MyClass _value_(즉, 생성자 함수) 전에 MyClass _type_을 고려하는 것이 $# typeof f(MyClass) 에서 의미가 있습니다. 전자는 Ret = number 로 연결되고 후자는 error: MyClass is not a type 와 같은 결과로 이어집니다.

_type_과 _const value_를 모두 참조하는 이름에 동일한 논리가 적용됩니까? 귀하의 예에서 이는 number 유형이 항상 const 값 number 보다 우선한다는 것을 의미합니다. @RyanCavanaugh에 대한 생각이 있습니까?

맞습니다, 우리는 이것을 타입 표현식의 일반적인 의미로 해결할 것입니다( 마치 var x: [whatever] 를 작성한 것처럼). 따라서 typeof f(MyClass) 는 인스턴스 측에서 f 를 호출하는 것을 참조하고 typeof f(typeof MyClass) 는 생성자 함수로 f 를 호출하는 것을 참조할 수 있습니다.

그렇다면 @SaschaNaz 의 예제는 number 를 _const 값_이 아닌 _type_으로 명확하게 참조하고 있지 않습니까?

const number = "number";
type Ret3 = typeof f2(number); // Promise<string[]>

@RyanCavanaugh 세 번째 사용 사례 그룹이 범위를 벗어났는지 확인할 수 있습니까? 예를 들어 OP에서:

// Declare an interface DRY-ly and without introducing extra type names
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: typeof (<MyInterface>null).prop1.big.complex; // OK: prop2 type is {anonymous: {type: {}}}
}

이 사용 사례(구문에 관계없이)는 현재 지원되지 않습니다. 맞습니까?

this 표현식을 허용하여 이 문제를 다루어야 한다고 생각합니다.

   prop2: typeof this.prop1.big.complex;

const 문제는 다른 typeof 에 의해 해결되어야 한다고 생각합니다.

type Ret3 = typeof f2(typeof number); // typeof number is string so error here

... 이렇게 하면 typeof data[LOBOUND] 차단됩니다.

@mhegazy typeof this 좋은 아이디어입니다. 나는 이것이 이 제안을 위해 만든 분기된 구현에서 이미 작동한다는 것을 깨달았습니다. 글쎄, 그것은 수업을 위해 작동합니다. 인터페이스의 경우 오류가 없지만 this 유형은 항상 any 로 유추됩니다. 분기된 impl의 현재 출력:

class MyClass {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is {anonymous: {type: {}}}
}

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is any
}

인터페이스 선언 내에서 this 를 추론할 수 있습니까? 아니면 이 기능이 클래스로 제한되어 있습니까?

#6179와 Angular에 대해 두 가지 요점을 말하고 싶습니다.

// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(token: string) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return MyAPI;
}
type MyAPIConstructor = typeof myAPIFactory(null, 0); // OK: MyAPI is myAPIFactory's return type
function augmentAPI(api: MyAPIConstructor) {...} // OK

1. 매개변수의 수는 클 수 있습니다. 15개의 매개변수를 가정해 보겠습니다. 동시에 오버로드가 없으며 typeof 의 매개변수가 필요한 오버로드만 있습니다. 따라서 이 경우 다음과 같은 구문을 생각할 수 있습니까?

   type MyAPI = typeof myAPIFactory(...);
   

2. 팩토리 함수는 일반적으로 자체 전역 변수에 할당되지 않습니다. 함수 표현식이 사용됩니다.

   angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) { /*...*/ });
   

   그게 보통의 모습입니다. 여기서 알 수 있듯이 typeof 는 전혀 사용할 수 없습니다.

@thron0 내 직관은 매개변수가 몇 개 이상 있지만 _또한_ 익명 유형을 반환하는 것은 매우 드물다는 것입니다. 어떻게 생각해?

Angular 1이 더 일찍이 아니라 희귀해지면 희귀해질 것입니다.

기본적으로 설명하신 내용은 일반적인 Angular _factory_가 무엇인지입니다.

매개변수가 몇 개 이상 있지만 익명 유형을 반환하는 것

종속성을 매개변수로 사용하고 _service_의 인스턴스를 생성하는 함수입니다. 많은 수의 매개변수가 번거로울 수 있다고 생각할 수 있지만 문제는 이러한 팩토리가 직접 호출되지 않는다는 것입니다. DI 컨테이너가 이를 호출합니다. 팩토리는 어떤 것이 의존성으로 반환 값(서비스)을 요구할 때 호출됩니다. 그리고 서비스는 Angular에서 항상 싱글톤이므로 한 번만 호출됩니다. 그러나 서비스는 무엇이든 될 수 있으므로 싱글톤이 아닌 동작이 필요한 경우 팩토리는 생성자(또는 팩토리 함수)를 반환할 수 있습니다. 이 코드 예제에서처럼:

angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(token: string) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return MyAPI;
});

이 상황에 대한 현재 해결 방법은 다음과 같습니다.

class MyAPI {
    // dependencies (1)
    protected $http: HttpSvc;
    protected id: number;

    constructor(token: string) {...}
    foo() {...}
    bar() {...}
    // Static properties cannot be used with this approach because:
    // 1) this class is a global variable so it can be shared by different 
    // instances of the DI container,
    // 2) the id property isn't available here as it's initialized in the subclass
    //// static id0 = id;
}

angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) { // (2)
    return class extends MyAPI {
        $http = $http; // (3)
        id = id;
    };
});

// this type is needed for type annotations in the services that require MyAPI as a dependency
type MyAPIConstructor = typeof MyAPI;

angular.module('app').factory('someOtherService', function(MyAPI: MyAPIConstructor) {
    var api = new MyAPI('qwerty');
    /* ... */
});

보시다시피 완전히 추하고 고통 스럽습니다. 종속성을 세 번 나열해야 합니다. 더 많은 종속성이 있는 경우 일반적인 방식(팩토리 함수 내부)으로 클래스를 작성하고 해당 소비자를 위한 인터페이스를 선언하는 것이 더 간단합니다.

안녕하세요, 저는 typeof 구문/의미론을 그대로 두고 대신 간단한 유형 액세스 대수학을 구현하는 것을 제안하고 싶습니다.

유형 구문 확장을 상상해 봅시다.

type          ::=  ... |  literalType | type typeAccess | guarded
guarded    ::= "type" id
literalType   ::= stringLiteral | numberLiteral | symLiteral | booleanLiteral 
typeAccess    ::= typeField | typeSubscript | typeCall
typeField     ::= "." id
typeSubscript ::= "[" type "]"
typeCall      ::= "(" [type {"," type}] ")"

범위의 각 식별자는 두 엔터티에 동시에 바인딩될 수 있습니다.

• 컴파일 시간 유형
• 런타임 값

유형 가드는 전자만 추출합니다. 따라서

class A {}
var a: A;

와 동등하다

class A {}
var a: type A;

이 경우 수업이 있다면

class ABC {
    a: number;
    b(x: number): string;
    c:string[];
    d:[number, string];
}

그러면 우리는 쓸 수 있습니다

var a: (type ABC).a; // number
var b: (type ABC).b(number); // string
var c: (type ABC).c[number]; // string
var d: (type ABC).c[0]; // number

또한 어휘 범위에서 동일한 식별자 아래 _type_ 엔터티와 _value_ 엔터티를 병합하는 방법을 다룹니다.

interface SAME {
    x: number;
}
namespace SAME: {
    export type x = boolean;
    export var x: string;
}

var a: SAME.x   // boolean
var b: (type SAME).x  // number
var b: (typeof SAME).x  // string

@RyanCavanaugh , @sandersn 이 아이디어를 검토할 수 있습니까?

제안서에 표현 유형을 어떻게 포착합니까?

2016년 5월 19일 목요일 12:26 Anatoly Ressin은 알림 @github.com에서 다음과 같이 썼습니다.

안녕하세요, 저는 typeof 구문/의미론을 그대로 두는 것을 제안하고 싶습니다.
대신 간단한 유형 액세스 대수를 구현하십시오.

유형 구문 확장을 상상해 봅시다.

유형 ::= ... | 리터럴 유형 | 유형 액세스 | 경비
보호된 ::= "유형" ID
리터럴 유형 ::= 문자열 리터럴 | 숫자리터럴 | 심볼릭 리터럴 | 부울 리터럴
typeAccess ::= typeField | 유형첨자 | 타입콜
typeField ::= "." ID
typeSubscript ::= "["유형 "]"
typeCall ::= "(" [유형 {"," 유형}] ")"

범위의 각 식별자는 동시에 두 개의 식별자에 바인딩될 수 있습니다.
엔티티:

• 컴파일 시간 유형
• 런타임 값

_type_ 가드는 전자만 추출합니다. 따라서

클래스 A {}
에이: 에이

와 동등하다

클래스 A {}
에이: A형

이 경우 수업이 있다면

클래스 ABC {
a: 번호;
b(x: 숫자): 문자열;
c:문자열[];
d:[숫자, 문자열];
}

그러면 우리는 쓸 수 있습니다

var a: (ABC 유형).a; // numbervar b: (ABC 유형).b(숫자); // stringvar c: (ABC 유형).c[숫자]; // stringvar d: (ABC 유형).c[0]; // 숫자

또한 _type_ 엔터티와 _value_ 엔터티를 병합하는 방법도 다룹니다.
어휘 범위에서 동일한 식별자.

인터페이스 동일 {
x: 숫자;
}네임스페이스 동일: {
내보내기 유형 x = 부울;
내보내기 변수 x: 문자열;
}
var a: SAME.x // booleanvar b: (유형 SAME).x // numbervar b: (typeof SAME).x // 문자열

@RyanCavanaugh https://github.com/RyanCavanaugh , @sandersn
https://github.com/sandersn 이 아이디어를 검토할 수 있습니까?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/6606#issuecomment -220378019

귀하의 예는 typeof 점으로 구분된 표현식과 type 속성 유형 #1295가 매우 유사한 제안임을 상기시킵니다. 하나는 더 정적이지만 다른 하나는 더 역동적입니다.

typeof 키워드를 건너뛰는 아이디어도 마음에 듭니다.

   prop2: this.prop1.big.complex;

귀하의 예에서 @mhegazy 는 this-expression typeof 를 사용하고 있습니다.

prop2: typeof this.prop1.big.complex;

오늘 우리는 이것을 할 수 있기 때문에:

someProp: this;

내 생각에 더 많은 점으로 구분된 속성에 대한 위의 구문을 외삽하면 다음과 같습니다.

someProp: this.prop1.prop2.prop3;

그리고 아닙니다:

someProp: typeof this.prop1.prop2.prop3;

그리고 외삽을 계속하려면 typeof를 함께 건너뛰지 않겠습니까?

someProps: foo(number)

typeof를 함께 건너 뛰지 않는 이유는 무엇입니까?

내가 생각할 수 있는 한 가지 이유는 클래스의 인스턴스 쪽을 참조하는지 아니면 정적 쪽을 참조하는지 모호해지기 때문입니다.

class C {}

// Does 'x' have the instance type of 'C',
// or does it have the shape of its constructor?
let x: C;

다른 인터페이스 내에서 인터페이스의 속성 유형도 참조하고 싶습니다. 내 예를 #10588로 게시했으며 현재 이 티켓을 위해 폐쇄되었습니다.

다음과 같이 작성하는 것이 좋습니다.

interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<Foo.bar>; // OR: bar: Box<typeof Foo.bar>;
}

이것은 다음과 같이 번역됩니다.

interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<string>;
}

이전에 언급한 시나리오 중 일부는 이제 _색인화된 액세스 유형_으로 표현할 수 있습니다(#11929). 이 기능을 표준 typeof 표현식과 결합하면 다음과 같은 결과를 얻을 수 있습니다.

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: MyInterface["prop1"]["big"]["complex"];
}

그리고 그것은 작동합니다! (현재 typescript@next에 있음)

나는 다음과 같은 자연스러운 것이 비슷할 것이라고 생각하지만 함수의 경우 다음과 같은 "함수 호출 유형"이 있습니다.

interface FunctionLike{
    (arg1 : number, arg2 : string) : {a : number; b : string;}
}

type ReturnType = FunctionLike(number, string); // {a : number; b : string;} 

typeof 연산자와 자연스럽게 결합할 수 있도록

interface BigThing {
    testString: string;
    testNumber: number;
    testBoolean: boolean;
}

function getSmallThing(thing:BigThing){
    return {
        testString : thing.testString,
        testBoolean : thing.testBoolean
    }
}

type SmallThing = typeof getSmallThing(BigThing) // {testString: string; testBoolean : boolean}

그리고 이것은 이 스레드(@tinganho)의 시작 부분에서 이미 제안된 구문인 것 같습니다. :)
하지만 _색인화된 액세스 유형_이 지금 하는 것처럼 현재 typeof 연산자로 멋지게 구성되는 더 일반적인 기능이 될 것입니다.

그러나 몇 가지 질문/의심이 여전히 남아 있습니다.

• 이 기능이 _색인화된 액세스 유형_과 같은 다른 시나리오를 처리합니까? 그렇지 않다면 그것을 구현할 가치가 있습니까?
• 나는 대부분의 경우 인수 유형을 전혀 지정할 필요가 없는 것이 좋을 것이라고 가정합니다. 가장 일반적인 시나리오는 "다른 오버로드가 없는 하나의 함수 유형을 얻고 싶습니다."이기 때문입니다. 그래서 일부를 도입할 수도 있습니다. 이에 대한 새로운 특정 연산자는 괜찮을 것입니다(예 typeofreturn 또는 returnof )

기술적으로 가능한 것 같습니다. 인수를 확인할 필요가 없도록 오버로드 확인/유형 인수 유추를 리팩토링해야 할 수 있습니다. 제네릭이 추가 문제를 너무 많이 제기한다고 생각하지 않습니다. 한 가지 질문은 호출과 일치하는 과부하가 없으면 어떻게 되는지입니다.

이 기능이 바람직한지 여부는 분명하지 않다고 생각합니다. 함수가 매우 정교한 익명 유형을 반환하는 경우 이러한 방식으로 참조할 필요가 없도록 유형에 이름을 지정하는 것이 작성자에게 더 도움이 되지 않을까요? 나는 이것이 단지 문체 선호도에 근거한 것임을 인정합니다. 실전에서 얼마나 편리하게 사용할 수 있을지 모르겠습니다. 그래도 요소 액세스에는 괜찮다고 생각합니다.

유형 P = foo(0) 유형; // P는 임의[]
유형 Q = foo 유형(true); // Q는 문자열입니다.

매개변수를 유형별로 참조할 수 있도록 하는 방법에 대한 이 논의에서 실제 기능에도 동일하게 허용하는 것이 좋습니다.
컨텍스트: 개체에 대해 map 에 함수를 입력하고 싶습니다.
function map<T, F extends Function>(fn: F, obj: T): { [P in keyof T]: typeof F(T[P]) }
F (이름 fn 제외)로 함수를 참조할 수 있기를 원하는 이유는 이름을 사용할 수 없는 경우입니다. 예를 들어 I' type MapFn<T, F extends Function> = { [P in keyof T]: typeof F(T[P]) } 라고 말할 수 있습니다.

구현하기 훨씬 쉽고 여전히 매우 유용할 수 있는 것은 다음과 같습니다.

const myFunc = () => ({ x: 10 });
type myType = returnof myFunc;    // { x: number; }

이론적으로 유형을 몇 수준 깊이로 가져오려는 경우에도 연결될 수 있습니다. 이견있는 사람?

편집: @mpawelski 😄가 위에서 언급한 것을 방금 깨달았습니다.

@dehli 오버로드된 기능에서는 작동하지 않습니다. 또는 형식 매개 변수가 반환 형식에 사용되는 일반 함수입니다.

@JsonFreeman 다양한 반환 유형을 OR 함수에 오버로드할 수 없습니까? 그리고 일반 함수를 사용하려면 유형을 지정해야 할 수 있습니까?

가능하겠지만 얼마나 유용할지 모르겠습니다. 사람들은 더 세련된 것을 원하는 것 같습니다.

정말 고통스럽기 때문에 이것이 곧 시행되기를 바랍니다.

해결 방법

마지막 해결 방법이 더 이상 작동하지 않으므로 현재 다음을 사용합니다.

// 0 argument function
export default function returnof<T>(fn: () => T): T;

// 1 argument function
// If no ambiguity simply infer the return type
export default function returnof<A, T>(fn: (a: A) => T): T;

// 1 argument function, with possible overload for the argument type.
// Explicitly set the type and use the correct overload
export default function returnof<A, T>(fn: (a: A) => T, a: A): T;

// ...

함수에 과부하가 없으면 인수를 지정할 필요가 없습니다.

const hello = (arg: number) => 'World'

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // string

오버로드된 함수

declare function hello(): void;
declare function hello(a: number): number;

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // void

const helloReturnValue = returnof(hello, 42)
type helloReturnType = typeof helloReturnValue // number

모든 정의는 다음과 같습니다.
https://github.com/kube/returnof/blob/master/lib/returnof.d.ts

프로젝트를 오염시키지 않고 쉽게 묶을 수 있는 작은 NPM 패키지 를 만들었습니다.

Optional Generics가 https://github.com/Microsoft/TypeScript/issues/2175 에서 제안된 것처럼 추가되면 간단한 선언적 해결 방법이 허용됩니다.

type Return<T extends () => S, S> = S

다음과 같이 사용하십시오.

type helloReturnType = Return<typeof hello>

@mhegazy @JsonFreeman 이 기능에 대한 계획이 있습니까?

안녕하세요 여러분,
나는 이 문제에 대한 대안이 될 수 있는 해결책을 가지고 있습니다(이미 제안되었고 제가 놓쳤다면 죄송합니다) - 문제 #13949에서 제안했습니다. 나는 그 단계에서 typeof 연산자에 대해 알지 못했지만 내 솔루션이 더 일반적이라고 생각합니다. 기본적으로 =MyType 와 같은 새로운 구문을 도입합니다. 이 구문은 MyType 를 사용하는 모든 곳에서 사용할 수 있지만 객체를 MyType 유형으로 선언하는 대신 개체의 유추된 유형에서 MyType 라는 유형입니다. 예를 들어 이것이 Vue 구성 요소를 만드는 데 사용하는 방법입니다.

function createData(){
  return <=MyData>{
    dataProp1: <string>null
  }
}

function method1(){
  let self: MyComponent = this;
  console.log(self.dataProp1);
  self.method2();
}

function method2(){
  let self: MyComponent = this;
  //dostuff
}

type MyComponent = MyData & MyMethods;

let componentOptions = {
  data: createData,
  methods: <=MyMethods>{method1, method2}
}
//todo: register component...

createData 함수는 다음과 같이 작성할 수도 있습니다.

function createData(): =MyData {
  return {
    dataProp1: <string>null
  }
}

어떤 식으로든 일반화할 수 있는 정말 재미있는 방법을 찾았습니다.

const varWithRightType = (false as true) && some.deep.access()
type MyType = typeof varWithRightType;

편집: 그만 웃으세요 이것은 심각한 조판입니다

@johnfn 이것은 간단한 경우에 재미있어 보이지만 함수에 일부 매개변수가 필요한 경우 다음과 같이 추가 작업을 수행해야 합니다.

const stateProps = (false as true) && mapStateToProps({} as any);

저는 mapStateToProps 함수에서 props 유형을 가져오기 위해 유형 추론을 사용하려고 할 때 React & Redux에 특히 유용한 다른 해결 방법을 사용하고 있습니다. 그러면 더 이상 유지 관리가 번거롭고 오류가 발생하기 쉬운 Redux connect 에 의해 주입된 Props의 인터페이스를 수동으로 선언하고 유지 관리할 필요가 없습니다.
이 해결 방법은 다른 사용 사례에 대해 주어진 함수 서명도 훌륭하게 처리합니다.

typeof 연산자 "React & Redux" 사용 사례의 예:

아래 예제에서는 TypeScript에 추가하면 매우 유용할 함수 선언에서 유형을 파생하기 위해 typeof 연산자를 사용하는 일반적인 실제 프로젝트 사용 사례를 보여줍니다.

import { returntypeof } from 'react-redux-typescript';
import { RootState } from '../../store';
...

const mapStateToProps = (state: RootState) => ({
  currencies: CurrencyRatesSelectors.getCurrencies(state),
  currencyConverter: storeState.currencyConverter,
});

const stateProps = returntypeof(mapStateToProps); 
type Props = typeof stateProps & typeof dispatchToProps;
type State = {};

class CurrencyConverterContainer extends React.Component<Props, State> {
...

출처: https://github.com/piotrwitek/react-redux-typescript-patterns#react -connected-components

@kube 의 솔루션과 패키지 https://github.com/kube/returnof 가 예상대로 작동하는 것 같습니다! 👍

흠. returnof 가 .d.ts 파일에서 튜플 기반 map() 을 입력하는 데 도움이 되었으면 하지만 표현식 언어에 대한 의존성을 감안할 때( const 는 주변 컨텍스트에서 사용할 수 없습니다. ), 나는 그것에 대한 나의 사용 사례가 적어도 더 복잡할까봐 두려워합니다.

편집: 지금까지 선택적 제네릭이 병합 된 것 같습니다. 즉, @kube 의 선언적 유형 언어 전용 버전( type Return<T extends () => S, S> = S -> type helloReturnType = Return<typeof hello> )이 실행 가능하게 될 것입니다. :디

수정: 아니요, 기본 제네릭 값에 대한 병합된 지원은 제네릭의 일부를 지정하는 것을 허용하지 않는 것 같습니다. Return<typeof hello> 는 Generic type 'Return' requires 2 type argument(s). 오류를 생성합니다.

@tycho01 네, 문제가 해결되지 않아 실망했습니다.

선택적 일반 유형 추론 에 대한 관련 문제를 이미 열었습니다.

14400

일반적으로 더미 앰비언트 함수와 유형 추론의 조합을 통해 함수의 반환 유형을 얻을 수 있습니다.

주변 function returnTypeOf<RT>(fn:(...rest:any[])=>RT):RT {return void 0};
로컬 var r = returnTypeOf(someFunction); 는 undefined 값을 얻습니다.

그러나 해당 반환 유형을 재사용하려면 캡처해야 합니다. 그래서 우리는 처음 시작했던 곳으로 돌아갑니다.

type RT = typeof r;

처음에 typeof 의 개념을 확장하여 returntypeof #$ 를 허용하거나 typeof fn(a,b,c,...) 에서 이 사용법을 더 잘 추론한 다음 다른 서명 반환 유형을 캡처할 수 있다면 훨씬 더 쉬울 것입니다. . 이 반환형 이해는 이미 TS에서 내부적으로 수행됩니다.

typeofexpression () 는 유형 연산과 혼합된 일종의 반환 유형 재귀입니다. 예:

type E = typeofexpression (f(1) + g("x"))

~이다

type E = typecomprehensionof (typeof f(1) + typeof g("x"))

다음 중 하나처럼 이해될 수 있습니다.

type E = typecomprehensionof (string + string) 즉 string
type E = typecomprehensionof (string + number) 즉 string
type E = typecomprehensionof (number + number) 즉 number

이것이 내부적으로 얼마나 어렵고 성능 비용은 나에게 알려지지 않았습니다.

편집하다 ------------------------------------------------- ----------

추가하려는 ... 이것은 Function.bind, Function.apply, Function.call을 사용해야 하는 모든 사람에게 특히 중요합니다. 왜냐하면 이들은 현재 any 유형을 반환하고 이는 지속적으로 유형이 되어야 함을 의미하기 때문입니다. 유형 검사 프로세스에서 빠지지 않도록 주석을 달았습니다.

함수 인수의 반환 유형을 참조할 수 있다는 것은 ... bliss ...

@poseidon코어

함수 인수의 반환 유형을 참조할 수 있다는 것은 ... bliss ...

나는 현재의 typeof <expression> 가 더 좋으며 반환 유형 문제는 #12342에서 이미 다룹니다.

설명에서 이러한 사용법을 구별하는 수단으로 typeofexpression 및 typecomprehensionof 를 사용했습니다. 실제 구문으로 typeof (expression) 를 선호합니다.

내 요점은 표현식의 유형을 이해하려면 함수의 반환 유형을 이해해야 한다는 것입니다... f(1) 도 표현식입니다. #12342 는 이런 식으로 관련되어 있습니다. 그것들은 상호 배타적이지 않습니다.

우리는 이미 변수에 대해 typeof 를 수행할 수 있으며 표현식은 변수와 함수에 대한 연산이므로 다음 요구사항은 함수의 유형을 반환할 수 있어야 하고 ... 그리고 유형 규칙에 따라 결과를 이해할 수 있어야 합니다. .

사실 좋은 지적입니다. #12342가 원하는 문제는 제네릭 유형에 대한 일종의 속성과 같은 것으로 반환 유형에 액세스하는 방법이므로 관계를 잘못 이해했습니다.

제안에서와 같이 typeof 함수 호출에 표현식을 사용하지만 매개변수 대신 유형을 직접 사용하는 것은 어떻습니까?

예

function myFunction<T>(param1: T, param2: string, param3: number): T & {test: string} {
  // ...
}

type ResultType = typeof myFunction({hello: string}, string, number)
// ResultType is: {hello: string} & {test: string}

이것은 호출 내에서 typeof를 사용하여 로컬 범위 변수 유형을 사용하는 것을 막지 않습니다. 예:

type ResultType = typeof myFunction(typeof obj, string, number)
// ResultType is: typeof obj & {test: string} 

이것은 주변 컨텍스트에서 작동하고 일반적으로 더 유연해 보이기 때문에 원래 제안보다 조금 더 나은 것 같습니다. 나에게 그것은 또한 우리가 실제로 함수를 호출하는 것이 아니라 반환 값의 유형을 반환하려고 한다는 것을 더 명확하게 합니다.

내 간단한 경우에 어떻게했는지 :

interface IAlertMessage {
  addedAt: number;
  text: string;
  type: "error" | "warning" | "info" | "success";
}

declare let alertMessageInterface: IAlertMessage;

const messages: IAlertMessage[] = [];

function addMessage(text: string, type: typeof alertMessageInterface.type): void {
  messages.push({addedAt: new Date().getTime(), text, type});
}

addMessage("something", "info"); // <- OK - and also has intellisense for the second parameter (after typing first " of the second parameter, press Ctrl+Space in VSCode)
addMessage("something", "fatal"); // <- Compilation error : error TS2345: Argument of type '"fatal"' is not assignable to parameter of type '"error" | "warning" | "info" | "success"'.

위의 내용은 인터페이스 자체의 멤버에서도 작동합니다.

declare let myIface: MyInterface;

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },
    prop2: typeof myIface.prop1.big.complex.anonymous;
}

type ... declare let ... 를 사용하는 이점은 출력 .js 파일에 아무 것도 생성하지 않는다는 것입니다.

@varadero 이것은 함수 호출의 반환 유형을 검색하는 당면한 문제를 해결하지 못합니다. TypeScript 2.2부터 지원되는 기능인 유형의 속성 유형을 검색하는 것뿐입니다.

그것은 실제로 (가짜) 값의 속성 유형입니다. 컴파일러는 "순수한" 유형 또는 인터페이스와 함께 typeof를 사용하는 것을 허용하지 않으며 값에 대해서만 작동합니다.

이것은 있으면 좋을 것입니다!

type KEYOF<T extends any[]> = keyof T[0] 가 이미 존재하기 때문에 function myFunc<T, K extends KEYOF<T>>(type: K)>{ } 및 myFunc([(r: string) => r]) 를 가정하면 $ typeof T[0]('something') 는 이 구현에서도 잘 작동합니다( typeof T[0]('something') 에 대한 문자열 반환). ?

이것은 다형성 this 와 함께 강력할 것입니다.

이것이 일어날 시간입니다!

이 스레드를 다시 읽으면서 우리가 typeof 구문으로 무엇을 하고 있는지, 왜 그런지 이해하려고 했습니다.

분명히, 이미 구현된 사소한 typeof foo 경우에는 foo 유형을 제공합니다. ( pet is Fish 는 특수 구문을 사용하는 데 면역이 있다고 생각합니다.)

현재 제안에서 이 키워드가 수행해야 하는 작업에 대한 나의 현재 읽기에서 키워드 자체는 현재 수행하는 것 이상을 수행하지 않으며 현재 제안은 실제로 typeof 키워드와 관련이 없습니다.

위에서 언급한 경우에 중요하기 때문에 이 문제를 제기합니다. 여기서 우리는 값이 아닌 유형으로 저장된 함수( type 를 통해 또는 일반으로)를 적용합니다.

이를 감안할 때 typeof fn<A>(string) 는 유형 수준에서 사용하기 위해 표현식 수준 변수 fn typeof #$가 필요하고 다른 한편으로는 Fn<A>(string) $가 필요하다고 가정합니다. , Fn 를 함수를 포함하는 제네릭으로 사용하면 이를 필요로 하지 않으므로 typeof 필요 없이 여기에 적절한 반환 유형을 얻기 위해 '적용'할 수 있습니다.

이 해석에서 우리는 Fn(...) 인 함수 유형 이후 typeof fn<...>(...) 함수 Fn<...>(...) 을 확인합니다 typeof fn(...) 리터럴 ((foo: Foo) => Bar)(Baz) / + 제네릭. 그렇지 않으면 공격 계획이 그대로 유지되어야 합니다.

아마도 나는 여러분이 이것을 어떻게 보는지 잘못 해석하고 있을 수 있습니다. 아마도 유형에 저장된 함수는 고려조차 하지 않았을 것입니다(내가 언급하지 않았기 때문에). 어느 쪽이든, 나는 그것이 확인할만한 가치가 있다고 생각했다.

함수 응용 프로그램을 발표하는 것이 typeof 에 대한 또 다른 의미론적 오버로드가 된다면, 클래스 생성자를 명확하게 하고 표현식 수준 변수를 유형 수준으로 들어올리는 것 외에도( 표현 수준 typeof 제외), 이 스레드의 몇 가지 이전 질문에서 이미 지적했듯이 점차적으로 더 복잡해 보입니다.

편집: 제네릭 유형은 이미 제네릭도 가질 수 있는 함수 유형을 반환할 수 있습니다. 이것은 또 다른 순열이 GetFn<A><B>() 가 될 것임을 의미하며, 첫 번째 제네릭 세트는 제네릭 유형 호출에 속하고 후자는 함수 호출에 속합니다. GetFn<A><B><C>() 는 아니지만 GetFn<A><B>()<C>() 도 합법입니다. 그러나 이전 결론은 변경되지 않았습니다. 모든 유형은 함수를 포함할 수 있으므로 (잠재적으로) 함수로 적용될 수 있습니다.

편집 2: X<Y>() 에 불행한 모호함이 있다는 것을 방금 깨달았습니다. 이제 X 는 함수 유형을 반환하는 유형이 됩니다.

• X 가 제네릭이 아닌 경우 이것은 분명합니다. <Y> 는 함수 호출에 속합니다.
• X 가 제네릭이고 매개변수가 필요한 경우 이것도 분명합니다. 이는 유형에 속하며 함수에는 유형 매개변수가 전달되지 않습니다.
• 그러나 X 에 선택적 제네릭이 있으면 이는 모호해집니다.
  
  
  
  • 한 해석에서 X 에는 유형 매개변수가 전달되지만 함수는 전달되지 않습니다.
  
  
  • 다른 해석에서 X 는 기본 유형 매개변수를 사용하도록 남겨두고 <Y> 는 대신 함수 호출을 매개변수화합니다.
  
  

여기서 가장 좋은 해결책이 무엇인지 아직 확실하지 않습니다.

• 한 가지 옵션은 기본 유형 매개변수에 완전히 의존하는 유형 호출을 강제 실행하여 이를 건너뛰는 것보다 명시적으로 비어 있는 <> 를 사용하는 것입니다. 그러나 이것은 획기적인 변화가 될 것입니다.
• 대안은 대신 유형 수준 함수 호출에 이러한 제한을 적용하는 것입니다. 이는 새로운 것이기 때문에 주요 변경 사항이 도입되지 않습니다. 그러나 이 접근 방식은 식과 형식 언어 간의 함수 호출 구문 사이에 비대칭을 도입하여 덜 직관적으로 만들 수 있다는 점에서 부적절합니다.

@icholy : 예, 이러한 편집은 귀하의 요점에 추가로 추가되고 있다는 것을 압니다.

편집 3: 좋아, 이 기능은 이제 내 위시리스트의 맨 위에 있습니다. 추론에 대한 영향 측면에서 원격으로 가까운 업그레이드는 없습니다.

@icholy : 간단히 말해서 '함수'가 일반/유형에 있으면 여전히 typeof 를 작성할까요?

이 작업이 수행되어 오버로드와 올바르게 상호 작용하면 실제로 "가변" 함수를 무료로 제공합니다(>1 arity를 ​​갖는 대신 커리 처리됨). 일부 기본 사례 과부하와 함께 과부하 중 하나의 적용. 이것이 Haskell에서 수행되는 방식이며 TypeScript에 있으면 멋진 기능이 될 것입니다.

@masaeedu : 흥미롭게 들립니다. 그리고 예, 오버로드는 확실히 이 제안을 매우 흥미롭게 만드는 것입니다. any 폴백이 포함된 다양한 옵션에 대한 패턴 일치에 사용할 수 있습니다. 그런 유형 검사는 아직 유형 수준에서 가능하지 않았습니다.

나는 Haskell보다 Ramda를 더 많이 사용했다는 것을 인정할 것입니다. 그러나 그 배경에서 나는 카레가 추가 인수를 처리하기 위해 결과를 반환할지 아니면 다른 함수를 반환할지 '알아야'하기 때문에 일반적으로 커링이 가변 함수와 잘 결합되지 않는다고 생각했습니다.

Object.assign ( & 대 Overwrite 와 같은 세부 정보 건너뛰기)와 같은 가변 함수에 대해 이 아이디어가 작동하는 방법에 대해 의사 코드를 표시할 수 있습니까? 내 PoC에서 R.mergeAll )?

@tycho01 저는 다음과 같은 코드를 가지고 놀았습니다.

interface Pop<TVarStack extends VarStack> {
    (a: TVarStack["head"]): Pop<TVarStack["tail"]>
}

interface VarStack<THead = any, TTail extends (void | VarStack) = any> {
    head: THead
    tail: TTail
    <TNew>(a: TNew): VarStack<TNew, this>
    (): (a: Pop<this>) => any
}

// Figure out implementation later :)
let stack: VarStack<void, void>;
const pop = stack(new Date())(10)("Bob's")("your")("uncle")()

// a, b, c, d, and e are well-typed
pop(a => b => c => d => e => {
    // Need this because can't figure out how to encode base-case in Pop recursion
    return stack
})

VarStack 는 임의의 수의 이기종 인수를 제공할 수 있고 유형 수준에서 재귀를 사용하여 연관된 유형 정보를 충실하게 기록한다는 점에서 "가변" 함수 유형입니다. 불행히도 TypeScript는 Haskell과 같은 방식으로 유형 수준에서 변환 및 패턴 일치를 잘 지원하지 않습니다.

typeof 에 액세스할 수 있다면 Pop 에 대한 기본 사례 문제를 해결할 수 있습니다 returnof(overloadedFunction(T)) 유형 수준에서 일치합니다.

@tycho01 Object.assign 에 대해서는 정확히 할 수 없습니다. 왜냐하면 제가 말했듯이 이것은 커리 함수에만 작동하지만 대략적으로 작동하는 커리 assign 함수를 만들려고 노력할 것입니다. 같은 방식으로.

예를 들어 (a: string) => (b: number) => void 가 Func<string, Func<number, void>> 에 대한 설탕이고 (a: string, b: number) => void 가 Arity<number, Arity<string, void>> 에 대한 설탕이 되도록 유형 대수학을 약간 일반화했으면 합니다. 그런 것. 그런 다음 새로운 흥미로운 기능을 많이 얻기 위해 유형을 변환하는 범용 도구가 필요합니다.

트리플 포스트에 대해 모두 사과드립니다. @tycho01 다음은 "variadic" 카레 assign 입니다.

interface Assign<TCurr extends {} = {}> {
    <TAdd extends {}>(a: TAdd): Assign<TCurr & TAdd>
    (): TCurr
}

let assign: Assign = undefined // implement somehow
const result = assign({ foo: "bar" })({ baz: 42 })()

@masaeedu : 하, 그래서 감속기 기능이 있는 것 같아요. :) 가변적이지 않은(?) 인수가 있으면 그 부분이 더 어려워질 수도 있습니다.

나는 그 아이디어를 좋아한다. 나는 확실히 인터페이스의 방향에 대해 많이 생각하지 않았습니다.
하지만 타이핑에 대한 JS를 변경할 수 있다면 아마도 TC39에게 Object.assign 를 가변적이지 않은 mergeAll 로 변경하도록 요청할 것입니다. :디

지금까지 실제로 함수를 사용하여 작동한 것과 같은 증분 기반 반복과는 다릅니다(#17086)... 하지만 어느 쪽이든 저는 이 제안이 제가 본 다른 제안보다 더 큰 영향을 미칠 것입니다.

@tycho01 가변 함수를 고정된 arity 함수로 바꾸도록 요청하면 JS(또는 최소한 기존 JS 엔진 및 코드)에 적용되는 커리 함수나 반복 애플리케이션에 런타임 비용이 들기 때문에 많은 관심을 끌지 못할 것 같습니다. 아마도 고도로 최적화되어 있지 않을 것입니다. 대신에 TypeScript가 arity > 1 함수에 대한 유형을 재귀적으로 쉽게 구축 및 분해할 수 있도록 하는 것이 필요하다고 생각합니다. 이 모든 것이 #5453으로 돌아오는 것 같습니다.

다른 사람들은 C++에 매우 유사한 기능이 있다는 것을 배우는 것이 흥미로울 수 있습니다: decltype(expression)

이 기능이 TypeScript에 적용됩니까?
나는 인수가 표현식인 원래 제안된 형식을 매우 선호하지만 표현식 위치에 유형이 있는 특수 구문을 사용하려는 TS 팀의 의도는 모든 것을 복잡하게 만들고 언어로의 상륙을 지연시킵니다.
우리는 이 주제를 계속 유지해야 합니다.

이 제안의 일부라도 구현할 수 있다면 정말 기쁠 것입니다. 즉, 이 싱글:
type A = typeof anotherVariable . 이 한 줄이면 모든 것을 할 수 있습니다. interface B extends A , <B & A> : B & A 등

나는 React에서 이런 종류의 사용 사례를 많이 보고 있습니다. 고차 구성 요소를 만들 때 구성 요소 클래스 선언에 현재 HOC임을 암시하는 것이 훨씬 더 어렵습니다.

내가 한 일은 두 개의 클래스를 만드는 것입니다. 한 클래스는 React.Component 를 확장하고 모든 추가 메서드를 추가하는 반면 HOC 함수 내부의 클래스는 render() 를 조작합니다.

@blindbox type A = typeof anotherVariable 는 이미 작동합니다:

var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));

function checkItem(item: typeof data) {
    // item is Array<{ raw: number; square: number; }>
}

@Igorbek 와우, 맞습니다.

좋아, 나는 그것이 내 끝에서 작동하지 않는 이유를 알아 냈습니다.
이것은 작동하지 않습니다

interface B {
  thisIsB: boolean
}

const typeTest = (type: any) => {
  return 1 as any as App & B
}
type A = typeof typeTest(1)
declare const aVal: A; // aVal's type isn't of type App & B, but something else.

그러나 이것은 작동합니다.

interface B {
  thisIsB: boolean
}

const typeTest = (type: any) => {
  return 1 as any as App & B
}
const typeTestVal = typeTest(1)
type A = typeof typeTestVal
declare const aVal: A; // aVal's type is of type App & B!

예, 문제는 제네릭 형식 인수를 사용해야 하는 경우와 같은 특정 사용 사례에서는 사용할 수 없다는 것입니다.

function someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item: T) { ... }

// it is impossible to work this around because there's no chance to create a fake variable that would be parameterized by T
function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

@이고르벡 :

나는 인수가 표현식인 원래 제안된 형식을 매우 선호하지만 표현식 위치에 유형이 있는 특수 구문을 사용하려는 TS 팀의 의도는 모든 것을 복잡하게 만들고 언어로의 상륙을 지연시킵니다.

그래서 그들이 그것을 쓴 이후로 우리는 문자열과 숫자에 대한 리터럴을 얻었습니다. 즉, 상황이 좀 더 모호해지고 있습니다. 둘 다 작동합니다. 리터럴 배열과 객체는 유사하게 유형 표기법과 유사하게 보입니다.

따라서 변수, 제네릭, 기타 유형과 같은 값/유형도 저장했습니다. 유용한 정보를 얻으려면 여기에서 일부만 해결하면 안 됩니다.
여기서 유형 기반 접근 방식에 대한 좋은 논거는 이러한 혼합을 허용하는 것이 유형 수준에서 무료로 제공된다는 것입니다. 즉, 유형 수준에서 이미 typeof myVar 라고 말할 수 있습니다. 즉, 이 함수 'application'이 유형 수준에 추가되면 저장된 유형과 일반 변수를 모두 자동으로 연결할 수 있습니다. .

원래 제안된 접근 방식에 대한 추가 생각을 보고 싶습니다. 확실히, 그것은 유형 수준에 조금 더 노출시키는 역할을 할 수 있습니다. JS 기반 연산자( ! && || + - * / instanceof ) 및 TypeScript 특정 연산자(어설션 연산자 ! ).
이러한 JS 연산자에 대한 문제는 ... 해당 리터럴 결과 유형을 생성하기 위해 리터럴에서 작업할 수 있도록 허용하는 것이 현재 범위( ref )를 벗어난 것으로 간주되기 때문에 그대로 유형 수준에서는 거의 쓸모가 없습니다. -- expression -level 1 + 1 는 number 유형을 생성하고 다른 유형도 유사합니다.
이것을 염두에 두고 나는 유형 기반 제안에 대해 다소 실망했습니다.

이 기능이 TypeScript에 적용됩니까? [...] 우리는 이 주제를 계속 유지해야 합니다.

나는 이 제안을 작은 증상 에 대한 보다 일반적인 해결책으로 제안했지만 성공은 제한적이었습니다.

@tycho01 typeof 의 표현식 기반 변형에 대한 내 주장은 @yortus 가 원래 언급한 것과 거의 같습니다.

• 일관성 : 기존 typeof (유형 위치에서)는 이미 표현식으로 작동하지만 단일 기호를 허용하도록 제한됩니다. 따라서 유형 또는 의사 호출을 수락하면 표현식 및 유형 외에도 훨씬 더 많은 구문 분기인 훨씬 더 복잡한 구문이 도입됩니다.
  
  
  
  • 사용자는 새로운 구문을 배울 필요가 없습니다
  
  
• 단순성 : TypeScript는 눈에 거슬리지 않는 방식으로 이 기능을 구현하는 데 필요한 모든 기능을 이미 갖추고 있는 것 같습니다(PR에서 입증됨)
• 완전성 : 표현식은 항상 유형 주장( (undefined as any as <any arbitrary type can be here>) )을 사용할 수 있으므로 최소한 유형과 동일한 표현력을 갖지만 때로는 유형 시스템에 표현식으로 표현할 수 있는 유형이 부족합니다(spread 및 rest 유형은 이후에 도입되었습니다. 해당 표현이 착륙했습니다).

promised PR에 그 점을 알려주신 @tycho01님 감사합니다. (저는 실제로 귀하의 의견을 듣고 여기에 왔습니다), 이는 정말 간단하고 일반적인 기능이 굽지 않고 매우 우아한 방식으로 훨씬 더 복잡한 시나리오를 다룰 수 있음을 보여줍니다. 언어에 대한 매우 구체적인 행동으로.

나는 확장된 typeof 를 매핑된 유형/ keyof 과 같이 유형 시스템 표현력에 대한 실제 게임 체인저로 봅니다.

@Igorbek : 자세히 설명해주셔서 감사합니다. 어디서 왔는지 알겠습니다. 아마도 이 두 가지 접근 방식은 서로 다른 사용 사례를 제공할 것입니다.

현재 TS(또는 Playground의 2.3.3 )가 이미 많은 원래 시나리오를 작동하게 할 수 있으므로 원래 게시물보다 원래 제안의 현재 가치를 더 잘 보여주고 있다고 생각합니다.

// I have a strongly-typed collection but the element type is anonymous/unknown, how can I reference the element type? (#3749)

// Mapping to a complex anonymous type. How to reference the element type?
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));
declare function checkItem(item: typeof data[0]): any
// ^ no longer errors, needs no further change

// A statically-typed dictionary. How to reference a property type?
var things = { 'thing-1': 'baz', 'thing-2': 42 };
type Thing2Type = typeof things['thing-2'];
// ^ no longer errors, needs no further change

// A strongly-typed collection with special indexer syntax. How to reference the element type?
var nodes = document.getElementsByTagName('li');
type ItemType = typeof nodes.item(0);
// ^ the `.item` access works, but function applications still errors, would be fixed by either version of the proposal.

// A function returns a local/anonymous/inaccessible type, how can I reference this return type? (#4233, #6179, #6239)

// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
  class MyAPI {
    constructor(http) {}
    foo() {}
    bar() {}
    static id = id;
  }
  return new MyAPI($http);
}
declare function augmentAPI(api: typeof myAPIFactory(HttpSvc, number) /* ERROR */): any
// ^ function applications errors, would be fixed by either version of the proposal, if using slightly different syntax.

// I have an interface with a complex anonymous shape, how can I refer to the types of its properties and sub- properties ? (#4555, #4640)

// Declare an interface DRY-ly and without introducing extra type names
type MyInterface = {
  prop1: {
    big: {
      complex: {
        anonymous: { type: {} }
      }
    }
  },
  // prop2 shares some structure with prop1
  prop2: MyInterface['prop1']['big']['complex'];
}
// ^ no longer errors after swapping `.k` access to `['k']`. `typeof` was unnecessary and counter-productive -- MyInterface isn't exposed on the expression level.

이 예제는 더 이상 식이나 유형 접근 방식에 대한 사례를 많이 만들지 않는 것 같습니다. 대부분은 구식이며 사소한 기능 응용 프로그램은 둘 중 하나에 의해 활성화됩니다.

분명히 유형 수준 기반 함수 응용 프로그램은 tinganho, TS 팀과 나 자신이 typeof 를 통해 표현식 변수를 노출할 수 있지만 언급했듯이 유형 수준은 표현식에 노출된 기능보다 뒤떨어지는 경향이 있습니다. 수준. 이 함수 응용 프로그램 자체와 귀하가 언급한 확산 구문은 분명히 주요 예이며, 저는 분명히 이러한 문제가 해결되기를 바랍니다. 아마도 현재 격차의 대부분이 여기에서 해결될 수도 있습니다.

유사하게, 표현식 우선 접근 방식은 <MyType> whatever 또는 whatever as MyType 를 사용하여 유형을 주입하는 것도 허용하지만 유형 접근 방식에서 typeof 처럼 유사하게 사후 고려처럼 보일 것입니다. 유형/제네릭에 저장된 함수를 적용하는 방법이 남아 있으며, 이는 해당 유형 기반 접근 방식의 실제 부가가치의 대부분을 차지할 수 있습니다(거기에 언급되지는 않았지만) -- 유형 기반 조건문뿐만 아니라 고차 함수에 대한 정확한 추론 promised 스레드에서와 같이.* 더 나쁜 것은 OP의 사용 사례와 달리 해결 방법이 없습니다.

아이디어가 충돌하는 위치를 알 수 있다고 생각합니다. 현재 제안에는 typeof 키워드가 표현을 가치 수준으로 전환하는지 여부와 $ typeof 를 그대로 두는 것에 대해 (내 해석에 따르면) 모순된 견해가 있습니다. , 그러나 유형 수준에서 함수 응용 프로그램 구문을 노출합니다.

내가 보기에 그 모순은 다소 우연적이다. 나는 두 사용 사례의 합법성을 무시하지 않을 것입니다. 둘 다 구현된다면 의미 충돌을 피하는 추가 키워드를 볼 수 있습니다. 키워드가 어떤 식으로든 끝날지 여부는 솔직히 무관심합니다. 그냥 아무렇게나 입력하고 싶습니다.

*: 제네릭에서 해당 유형을 캡처하는 대신 매개변수 이름으로 매개변수의 함수를 참조하여 고차 함수를 사용할 수 있다는 것을 방금 깨달았습니다.
실제로 양방향으로 변환할 수 있는 것처럼 보입니다. typeof 는 가치 수준에서 유형 수준으로 올리는 데 도움이 되는 반면 declare let y: x; 는 가치 수준에서 유형 수준으로 물건을 올리는 데 도움이 됩니다. OP의 해결 방법처럼 우아하지 않지만 그렇습니다.
예를 들어 명시적 제네릭을 통해 함수 유형을 가져온 경우에는 이것이 도움이 되지 않을 것이라고 생각합니다. 이 유형은 이동할 방법이 없는 유형 수준에 있을 것입니다.
내가 선제적으로 기능 기반을 다루기를 희망하는 것처럼 들리면 아마도 해결되지 않은 입력 문제에 대한 나의 진행 상황이 이 하나의 추가 기능(5453에 대해 언급됨)에서 차단되었기 때문일 것입니다. 그러나 우리가 이러한 것들을 알아낼 수 있다면 그만한 가치가 있습니다.

편집: 지금은 표현식 기반 접근 방식에서 제외될 수 있는 몇 가지 이론적 사례를 생각해 보았지만 아직 실질적인 사례는 떠오르지 않았습니다.

• 명시적으로 제공된 제네릭을 통해 전달된 함수.
• 매개변수 함수에 의해 반환된 함수는 일반으로 캡처됩니다. 즉 (표현식 기반 제안의 구문을 사용하여) declare function f<G extends (...args: any[]) => R, R extends <T>(foo: T) => Bar<T>>(g: G): typeof R(baz); // error following the expression-based proposal: R is not exposed at the expression level . G 매개변수 유형을 알고 제공할 수 있다면 이러한 정보는 물론 계산할 수 있지만 지금까지 이 정보를 얻을 수 있는 방법은 없습니다(#14400?). 이 범주에는 위에서 언급한 AngularJS에서 사용되는 팩토리 기능에서 작동하는 기능이 포함될 것이라고 가정합니다.

@Igorbek 이 스 니펫으로 기대하는 것을 이해할 수 없습니다.

function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

그것은 순환 정의처럼 보입니다.

@masaeedu 죄송합니다.

( someFunctionWithComplexReturnTypeThatUsesGenerics f 로 전환)

function use<T>(item: typeof f<T>(undefined as any as T)) { ... }

자세히 설명하자면 현재로서는 가짜 변수를 도입하여 해결할 수 없는 문제입니다.

const _typeofItem = f<T>(undefined as any as T); // no T here
function use<T>(item: typeof _typeofItem) { ... }

BTW, typeof 의 우선 순위가 더 높기 때문에 현재 제안이 멤버 유형 쿼리 유형 연산자 T[K] 와 충돌한다는 것을 방금 깨달았습니다.

• typeof x[K] 는 현재 (typeof x)[K] 를 의미합니다. 여기서 K 는 _a 유형입니다.
• 표현식 기반 변형을 사용하면 모호성이 도입됩니다.
  
  
  
  • typeof x[k] 는 (typeof x)[k] $를 의미합니다. 여기서 k 는 유형입니다. 또는
  
  
  • typeof x[k] 는 typeof (x[k]) $를 의미합니다. 여기서 k 는 표현식입니다.
  
  

의미상 동일하기 때문에 실제로 typeof (x[k]) 를 선호하지만 확실한 변경 사항입니다.

Chrome의 개발자 도구를 사용했을 때 회원 연산자의 우선 순위가 더 높다는 것을 알았습니다. 어디서 찾았어?

@Igorbek : 예, 원래 게시물의 type Thing2Type = typeof things['thing-2']; 가 이미 작동하는 이유인 것 같습니다.

@dehli : JS 표현 수준을 TS 유형 수준과 비교하고 있습니다. 동일하지 않습니다. 하나는 브라우저/노드에서 실행되고 다른 하나는 TS 컴파일러에서 실행됩니다.

저는 개인적으로 TypeScript가 인덱싱된 유형 액세스보다 더 높은 우선 순위로 유형 수준 typeof 을 해결하는 것이 이상 하다고 생각합니다. 솔직히 말하면 거의 버그처럼 보입니다. (그 케이스가 실제로 테스트가 되었는지 궁금합니다.)

@tycho01 갓챠 . TS는 JS와 동일한 우선 순위를 사용한다고 가정했습니다.

@dehli 표현 수준은 동일합니다. 유형 수준에서 유사한 구문을 가진 또 다른 것이지만 문자열 대신 유형을 반환합니다.

우선 순위는 그들이 가질 것으로 예상했던 제한의 결과일 수 있다고 생각합니다. 그 기능이 확장되어야 한다면 이러한 고려 사항이 더 이상 합리적이지 않은 것처럼 보일 수 있음을 인정합니다.

또 다른 참고 사항으로, 제안의 두 버전이 모두 구현되어야 한다면 괄호는 우리가 이에 대한 수준을 명시적으로 유지하는 효과적인 방법이 될 것입니다. 나는 타협처럼 들리지 않는 것들을 생각해내는 데 어려움을 겪고 있습니다. 하지만 그렇습니다.

@Igorbek 이것이 임의의 표현식에서 typeof 에 대한 나머지 주요 사용 사례입니까? 우리가 #14400을 얻는다면, 내가 틀리지 않았다면 일반 사용자 정의 유형을 사용하여 우리에게 returnof 를 줄 것입니다.

14400은 일반 형식으로 returnof 를 제공하지 않습니다.

type Return<T extends () => R, R = any> = R;

// overloaded function
declare function f(item: number): number;
declare function f(item: string): boolean;

type fType1 = Return<typeof f>; // ??
type fType2 = typeof f(1); // number
type fType3 = typeof f('a'); // boolean

// generic function
declare function g<T>(item: T): T;

type gType1 = Return<typeof g>; // ??
type gType2 = Return<typeof g<number>>; // not supported syntax
type gType3 = typeof g(1); // number
type gType4 = typeof g<number>(1); // number
type gType5 = typeof g('a' as 'a'); // 'a'

나는 나머지 사용 사례를 모두 알지 못하며 아직 발견되지 않은 것 같지만 가장 타의 추종을 불허하고 매력적인 것은 다음과 같습니다.

• typeof 가 표준 과부하 해결을 사용하기 때문에 #12424로 얻을 수 있는 훨씬 더 강력한 _조건부 매핑된 유형_; @tycho01 은 promised 유형 PR #17077에서 우아한 예를 보여주었습니다.
• 제네릭 유형의 컨텍스트에서 함수/메서드 반환 유형 가져오기(이전에 보여드린 것처럼)

@masaeedu : 좋은 질문입니다. 짧은 버전은 @Igorbek 이 말한 것과 거의 같습니다. 해결된 구체적인 과제에 대한 자세한 내용을 보려면 #16392의 '필요한 주요 기능' 목록에서 짧은 목록을 찾을 수 있습니다.

여기에는 다음이 포함됩니다.

• 예를 들어 AngularJS에서 사용하는 것과 같은 팩토리 함수는 여기에서 원래 게시물에 연결된 세 개의 스레드를 참조하세요. - 실제로 이것은 새로 내장된 ReturnType 를 감안할 때 괜찮을 것입니다.
• 알려진 입력이 주어지면 reduce / map / filter / find -- 반복 및 검사와 관련된 모든 것에 대한 정확한 반환 유형을 갑자기 계산할 수 있습니다. stdlib.d.ts 는 거기에 도움이 될 것이며 Ramda/Lodash와 같은 FP 라이브러리도 마찬가지입니다. 실제로 모든 입력이 알려진 것은 아니지만(튜플보다 목록과 유사한 배열이 더 많음) 개체에 대한 map 및 filter 작업도 Partial 보다 더 잘 입력될 수 있습니다. 이는 redux(https://github.com/piotrwitek/react-redux-typescript/issues/1 참조) 및 Angular의 ngrx와 같은 더 나은 유형 상태 관리 라이브러리에 필요합니다. 잘 입력된 map 연산 없이는 DRY'er 입력 데이터의 유형 수준에서 원하는 결과를 계산할 방법이 없기 때문입니다.
• 현재 함수 합성 유형은 입력 종속 반환 유형도 고려할 수 없습니다.
• 갑자기 렌즈와 같은 타이핑을 시작하는 것이 가능해졌습니다. - 기술적으로 이것은 입력 종속 반환 유형이 있는 편집 작업에서만 여기에서 차단된다고 가정합니다. 정말 럭셔리입니다. 튜플을 변경하려면 여전히 #5453이 필요합니다.
  또한 다음을 가능하게 합니다.
• 지금까지 불가능했던 유형 수준에서 부울 리터럴로 작업
• flatMap - promised 제안과 같은 작업에 대한 래핑 해제 유형
• 유형/함수 입력에 제약 조건 추가, #15347의 주제 및 종속 유형에 대한 책 'Idris를 사용한 유형 주도 개발'에서 얻은 아이디어. 이것은 0 제수를 허용하지 않는다고 말하는 데 도움이 될 수 있습니다. 본질적으로 #4183의 주제인 유형에서 빼는 해킹입니다. 나는 아직 대부분의 사용 사례를 상상하지 못했다고 확신하지만, function div<B extends number, NotZero = { (v: '1') => 'whatever'; }({ (v: 0) => '0'; (v: number) => '1'; }(B))>(a: number, b: B) 와 같이 이것으로 할 수 있습니다. 일반적으로 Idris 언어는 길이 안전 벡터/행렬 연산으로 광고하지만 고차 함수에만 필요합니다.
• 위의 제약 조건 + IsUnion 를 사용하여 입력 유형에 대한 Union<T> / NonUnion<T> 제약 조건을 표현하는 방법입니다. -- 그 유형은 파산했고 더 이상 어떻게 해야 할지 잘 모르겠습니다.
• #5453 도 주어진다면 이것은 curry , Function.prototype.bind , Promise.all 와 같은 함수를 입력하는 데에도 도움이 됩니다.
• #13500에서 제안된 switch 논리, 여기서 함수 오버로드 패턴 일치를 통해 해결됨
• 유형 수준 유형 검사라고도 하는 #12424 및 #17077( promised )의 주제인 매핑된 조건부 유형입니다. 그러나 그것은 그것을 해결하지 못할 것입니다. 그것이 오늘날 어디서나 부울 리터럴을 생성하는 데 사용할 수 있다고 해도 이 #6606이 될 때까지 우리는 여전히 유형 수준에서 이러한 부울 리터럴을 기반으로 조건문을 작동/수행할 방법이 없었습니다. 그래도.
• 작업(예: Omit , Overwrite from #12215)과 같은 객체 유형에서 문자열 인덱스 존재 여부 확인, #12424의 내 설명 참조
• 위의 문자열 인덱스 확인을 기반으로 개체 프로토타입 메서드(예: toString , toLocaleString )의 이름과 일치하는 문자열을 확인하도록 개체 유형 속성 액세스를 수정하는 방법은 대신 문자열 인덱스로 확인됩니다. 프로토타입 방법보다 이전에 결함이 있는 내장 객체 속성 액세스에 의존했던 다른 모든 유형 작업에서 toString 객체 액세스와 관련된 결함을 잠재적으로 수정합니다.

편집: 작성 시점부터 조건부 유형(#21496)으로 채워진 사용 사례를 지웠습니다.

@Igorbek 의 표현 우선 접근 방식 제안은 (위 목록의 일부에 대한 알려지지 않은 응용 프로그램을 깨는 대가로-- 구석에 칠해지는 것이 두렵지만 아직 구체적인 것은 생각하지 못했습니다. ) 추가로 현재 이 함수 응용 프로그램(this #6606), spread/rest(#5453), 주장 연산자 ! (#17370), 공용체 유형과 같은 것을 포함하는 값과 유형 수준 간의 격차를 좁힐 것을 약속합니다. 유형 가드를 통한 뺄셈(#4183, 그렇지 않으면 위에서 언급한 제약 조건을 통해 달성 가능), 그리고 아마도 더 이상 내 머리 꼭대기에서 생각할 수 없습니다.

이 모든 절충안이 동일한 기능을 두 가지 방식(실제 유형 수준, 유형 수준에 포함된 액세스 식 수준)으로 액세스할 수 있도록 하는 이유와 같은 몇 가지 질문을 제기할 수 있다고 생각합니다.

편집: 추가 잠재적 문제로 위의 비교 댓글을 업데이트했습니다.

편집 2:

불행한 것은 원본 게시물이 null & 해결 방법 없이 일부 극단적인 경우만 작성할 수 있다고 믿게 했다는 것입니다. 그러나 실제로 이것은 주변 컨텍스트에 대해 알려진 해결 방법이 없는 현재 TS를 보류하는 중요한 기능입니다. .

이는 별도의 .d.ts 파일로 작성된 TS에 영향을 미친다는 것을 의미합니다. 이는 stdlib.d.ts 뿐만 아니라 원래 JS 프로젝트와 별도로 작성된 모든 DT 입력에도 적용되며 거의 변경되지 않습니다. JS 라이브러리는 Flow와 같은 대안에도 열려 있기를 원합니다.

(이는 .ts 타이핑에 훨씬 더 좋지 않습니다. OP의 '해결 방법'을 사용하는 유형은 표현식 수준에 영향을 미치지 않고 더 높은 수준의 재사용 가능한 유형으로 구성하는 것과 같이 매개변수화될 수 없기 때문입니다.)

@tycho01 목록 주셔서 감사합니다. 내가 소화해야 하는 링크가 많이 있습니다. 나는 유형에 대한 패턴 일치도 원하고 #6606은 문제에 대한 훌륭하고 실용적인 솔루션입니다. 그러나 값과 유형 수준에서 사물 사이에 혼란이 증가하는 것으로 보이며 #6606은 이 영역에서 개선되지 않을 것입니다.

이 기능이 필요한 이유는 다음에 해당하는 유형 표현식을 구성할 방법이 없기 때문입니다.

• 특정 유형의 인수와 함께 적용될 때 함수 유형의 반환 유형
• ( typeof K[L] 이전) 문자열 리터럴 유형의 키에 해당하는 객체 유형의 속성 유형
• (아마도 다른 사람들, 나는 당신의 목록을 더 자세히 검토해야합니다)

값 수준 구성과 형식 수준 표현을 함께 사용하지 않고 순수하게 형식 수준 표현을 구성하는 것이 실제로 가능 해야 한다고 생각합니다. (a: A) => B 또는 A | B 와 같은 유형이 Func<A, B> , Union<A, B> 와 같은 간단한 매개변수화된 유형에 설탕이고 매개변수화된 유형을 조작하기 위한 일반 도구가 있으면 좋을 것입니다. (HKT, Fundeps 또는 유형 가족 등).

건전성에 대한 과도한 초점은 TypeScript의 목표 중 하나가 아니라는 것을 알고 있지만, 이제 불투명한 방식으로 함께 상호 작용하는 많은 유형 수준 개념이 있습니다. 유형이 무엇인지에 대한 일종의 형식화와 유형이 다른 유형(하위 유형 지정, 구조 분해 등)과 상호 작용하는 방식에 대한 기계적 규칙을 규정하는 방법은 먼 길을 갈 것입니다.

값 수준 구성과 형식 수준 표현을 함께 사용하지 않고 순수하게 형식 수준 표현을 구성하는 것이 실제로 가능 해야 한다고 생각합니다.

오, 예, 저는 개인적으로 가치 수준 구성을 사용하려는 의도가 전혀 없었습니다. 이것이 제가 시도하는 전부입니다. 밸류 레벨이 필수였다면 나 자신도 여기 표현주의 진영에 있었을 것이다. :피

값과 유형 수준 사이의 격차는 대부분 좁혀질 것으로 예상되며(TC39가 TS보다 빠르게 이동합니까?) afaik에는 이미 뛰어난 유형 수준 제안이 있습니다(이전 게시물 하단 참조).

젠장, 나는 대부분의 사용자의 경험을 벗어나는 기능의 상당 부분에 대한 타이핑을 구성한다는 것을 알고 있습니다.
내가 보는 방식은 표준 라이브러리와 FP 라이브러리가 너무 잘 입력되어 TS 사용자가 이를 작성하고 추론이 자동으로 처리되도록 하는 것입니다.
TS에는 유형 수준 연산자가 몇 개밖에 없지만 이를 사용하여 실제 문제를 해결하는 것(주요 예는 #12215의 Overwrite / Omit 입니다)은 일반 웹 개발자에게 로켓 과학에 조금 못 미치는 것처럼 보일 수 있습니다. 젠장, 그것도 최근까지 우리를 데려갔고, 그것들은 아직 프로토타입/인덱스/심볼 증거도 아닙니다.

(a: A) => B 또는 A | B는 Func , Union 과 같은 간단한 매개변수화 유형의 설탕이었습니다.

뒤집어서 매개변수화된 유형을 별칭/유형 생성자로 만들 수 있습니다. Foo<Bar> 를 사용하는 유형 작업의 경우 항목이 하나로 단순화되는지 여부는 중요하지 않습니다. 설명에 맞는지 여부만 확인합니다.
이것은 stdlib.d.ts 가 하는 일과 거의 비슷합니다 -- foo[] 가 있지만 Array<Foo> 설명을 충족하므로 Array.prototype 타이핑과 함께 작동합니다.
실제로 도움이되는 것은 아닙니다.

type Union2<A, B> = A | B;
type TuplizeA<Tpl extends Union2<any, any>, A, B> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type a = TuplizeA<1 | 2>;
type TuplizeB<Tpl extends any | any> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type b = TuplizeB<1 | 2>;
type TuplizeC<Tpl extends Union2<A, B>, A, B> = [A, B];
type c = TuplizeC<1 | 2>;
// ^ need 3 arguments, maybe fixable with #14400
type TuplizeD<Tpl extends A | B, A, B> = [A, B];
// ^ need 3 arguments, maybe fixable with #14400
type d = TuplizeD<1 | 2>;

그래서 음, 해결하지 못했지만 kube의 #14400이 실제로 도움이 될 수 있다는 것을 깨달았습니다. 그리고 오늘 일찍 거기에서 당신을 보았습니다!
실제로 함수에 대해서도 마찬가지입니다. 이는 #14400이 함수 반환 유형뿐만 아니라 매개변수 유형도 수행할 수 있음을 상기시켜줍니다.

이 접근 방식은 현재 오버로드를 사용해야 하며 확장되지 않기 때문에 불행하지만 그렇습니다. 다시 일반화하기 위해 기본적으로 이러한 #6606 패턴 일치 오버로드를 사용하여 다양한 유형에 대한 올바른 옵션을 트리거합니다.
이를 사용하여 일반적으로 튜플 유형으로 변환한 다음 내 증분 방식 을 사용하여 반복하여 어떻게든 작동할 수 있다고 가정합니다.
공용체의 경우 튜플 유형으로 변환하는 더 예쁜 방법을 원했습니다. 그러나 임의의 순서를 추가하고 예쁜 구문/키워드도 생각할 수 없습니다.

편집: 해당 표현식/유형 수준 기능 격차를 다시 확인하려면 다음을 수행합니다.

• 기능 응용 프로그램: this #6606
• 어설션 연산자 ! (#17370): #6606 이후에 해결 됩니다.
• 유형 가드를 통한 공용체 유형 빼기(#4183): 위의 ! 의 일반적인 경우이며, 이 #6606도 제약 조건(예: 위의 NotZero )을 통해 달성할 수 있습니다.
• Spread/rest (#5453) -- 튜플이 그 위치에 도달할 때까지 조작할 수 없더라도 유사한 ArrayLike List 할 수 있습니다. 이 #6606을 사용하여 이제 적용되지 않은 함수에서 매개변수를 추출할 수 있다고 생각합니다. 적용 시점에 매개변수를 추출하는 경우(즉, 정확한 입력 값을 얻기 위해) 여전히 5453이 필요합니다.

요컨대, 이 제안이 실현된다면 표현식과 유형 수준 사이의 기능적 격차가 여기서 표현 지향적인 제안에 대해 그다지 큰 논쟁을 일으키지 않을 것이라고 말하고 싶습니다. 5453도 있었다면 더 이상 거기에 대해 생각할 수 없었습니다. 그리고 드문 예외의 경우 원래 게시물에 언급된 해결 방법은 여전히 ​​유효합니다.

이제 여전히 쉽게 만들 수 있는 주장은 표현식 기반 변형을 사용하면 유형 수준이 미러링 연산자를 따라잡기 전에도 이 기능이 JS 와 동일한 구문 으로 노출된다는 것입니다(해결 방법 없음). 학습 곡선을 줄입니다.

편집 2:

유형을 표현식 수준으로 가져오는 표현식 제안의 트릭 1 as any as MyType 이 함수 자체에서도 논리적으로 작동해야 한다는 것을 방금 깨달았습니다.

이것은 아마도 두 가지 버전에 의해 활성화된 실제 기능이 다소 유사해 보인다는 것을 의미합니다. 외적인 차이점은 대부분 typeof myVar (유형 버전) 대 myVar (표현식 버전)로 구성되어 함수 응용 프로그램에서 변수를 사용하는 것입니다. MyType (유형 풍미) 대 1 as any as MyType (표현식 풍미, 대안 declare let a: any; 다음 <MyType>a )에서 유형을 사용합니다.

둘 중 하나의 AST 변경 사항도 꽤 관리하기 쉬운 것 같습니다. 표현식 풍미는 대신 값 표현식을 가리키기 위해 typeof 결합이 필요합니다. type flavor는 기존 함수 응용 프로그램 구문( fn<T>(arg) )을 표현식에서 유형 수준으로 복사하여 위의 Ryan이 제안한 대로 기존 구현에 연결합니다.

그러면 다음과 같이 귀결된다고 생각합니다.

표현 풍미의 경우:

• typeof expr TS 유형 수준 지원 이전에 해결 방법이 없는 JS 구문 포함

유형 풍미의 경우:

• 우선 순위에 대한 주요 변경 사항 없음
• 해결 방법을 통해(또는 연산자가 따라잡을 때까지 다른 구문에 있는 경우 TS를 통해) 값 표현식을 계속 캡처할 수 있습니다.
• MyType 대신 1 as any as MyType : 표현식 레벨의 유형 레벨에 표현식 레벨에 유형 레벨이 없습니다.

지금까지 건드리지 않은 관련 주제 중 하나는 이 유형 수준 함수 '응용 프로그램'에서 this 바인딩을 제공하는 방법이었습니다. 이제 JS 델리게이트는 이것을 Function.prototype 메소드에 덮어쓰지만, 그대로는 유형 수준에서 이를 처리할 방법이 없습니다.

임의의 예제 구문, F (this: Foo, a: number, b: string) => SomeReturnType 함수 유형이 주어지면 F(MyA, MyB) : F(this: MyFoo, MyA, MyB) 로 호출될 수 있습니다.

this 바인딩을 덮어쓰지 않고 반환 유형을 계산하는 것은 여전히 F(MyA, MyB) 와 같으며, 다음 위치에서 이러한 함수를 사용하려고 하면 유형 수준 this 인수가 일반적으로 무시되는 방식을 미러링합니다. 표현 수준.

이 예제 구문의 장점:

• 선언 구문을 반영합니다.

이 예제 구문의 단점:

• 선언 구문을 반영합니다.

자, 이것은 이미 언어로 되어 있습니다!

너무 흥분하지 마십시오.

@DanielRosenwasser 는 유형 대신 리터럴에 대한 함수 호출을 사용할 수 있도록 하는 버그인 #12146을 지적했습니다.

_5분 후_

타다! 우리가 프로덕션에서 절대 사용해서는 안 되는 끔찍한 사악한 것입니다. 하지만 유혹적이다...

interface String {
    passthrough<T>(v: T): T;
}

// All work
type ANumber = "".passthrough(10 * 10);
type AString = "".passthrough("hello" + "world");
type AHelloWorld = "".passthrough("hello world");
type AnArbitraryThing = "".passthrough(Object.assign({hello: "world"}, {foo: "bar"}));
type ThisCraziness = "".passthrough((() => "cows are big dogs"));

~그래서 이 문제에 대한 Effort: Difficult 가 약간 의심스러워 보입니다. 마치 그들이 거기에서 우연히 그렇게 한 것 같습니다.~ 더 읽고 어리석게 느껴집니다. 이것은 멋지게 하기가 _ 어렵습니다.

즐거운 시간 보내세요 @tycho01.

@TheOtherSamP TypeScript 2.4.2에서 이것을 시도했고 이러한 모든 유형은 any 인 것으로 유추됩니다.

@pelotom Huh, 2.4.2 및 2.5.0-dev.20170803에서 작동합니다. 대상 es6 및 엄격 모드.

그들이 방금 고친 것 같지만 내 잘못이 아닐까 걱정됩니다. #17628

@TheOtherSamP 아니요, 주사위가 없습니다. 오 글쎄.

@pelotom 이상하네요. 완전히 새로운 프로젝트에서 작동하고 있습니다. 설정이 어떻게 다른지 모르겠습니다.

@TheOtherSamP : 하하, 꽤 웃기네요.
시간적으로 보면 그들이 당신의 코멘트보다 조금 전에 수정을 시작한 것처럼 보입니다. 오 글쎄.

@펠로톰 :

TypeScript 2.4.2에서 이것을 시도했고 이러한 모든 유형이 any로 유추되었습니다.

그의 스니펫은 Playground(2.3.2)에서 작동하는 것 같습니다. 그것 외부의 최신 버전( ^2.5.0-dev.20170626 )에서도 재생산하는 데 문제가 있습니다.

그래서 이 문제에 대한 Effort: Difficult 가 약간 모호해 보입니다. 마치 그들이 거기서 우연히 한 것처럼 보입니다.

그들은 유형 기반 구현을 참조했는데 이는 일부 변경을 의미하는 반면 표현식 언어(-> + , Object.assign , 추가 함수 호출)를 사용하는 것으로 보입니다.

@tycho01 #17618에서 관심을 끌면서 모든 것이 _생각_합니다. 글쎄, 그것은 나를 프로덕션에서 사용하는 것을 진지하게 고려하는 법을 가르쳐 줄 것입니다.

그들은 유형 기반 구현을 언급했는데 이는 일부 변경을 의미하는 반면 표현식 언어(-> +, Object.assign, 추가 함수 호출)를 사용하는 것으로 보입니다.

네, 저는 바보였고 그 말을 할 때까지 이 전체 문제를 읽지 않았습니다. 그것은 아마도 기능의 더 나은 버전일 것입니다. 그러나 우리가 지금 그것을 가질 수 있기를 바랍니다. 나는 타입 시스템의 한계를 많이 뛰어 넘었고, 이것이나 #12424는 많은 선택지를 열어줄 것이다.

#17961에서 PR을 열었습니다.

@yortus 이것은 'typeof literal'의 경우를 커버합니까?
오늘날 TypeScript는 "const x: typeof 1 = 1;"을 쓰는 것을 허용하지 않습니다.

@NN--- 원래 제안은 모든 표현식을 다루지만 '승인된' 부분은 속성 액세스 및 함수 반환 유형만 다룹니다.

typeof 1 가 허용되더라도 리터럴 유형( 1 ) 또는 더 넓은 유형( number )을 제공할지 확신할 수 없습니다.

오늘날 TypeScript는 "const x: typeof 1 = 1;"을 쓰는 것을 허용하지 않습니다.

왜 const x: 1 = 1; 가 아닌가요?

@SaschaNaz 나는 다음과 같은 것을 쓰고 싶었습니다.

const a = {q:1};
const b = {q:1};
const x: ReadonlyArray<typeof a> = [a,b];

그러나 리터럴에서는 이와 유사하게 작동하지 않습니다.

const x: ReadonlyArray<typeof 1> = [1,2,3];

@yortus 정확한 유형에 대한 좋은 지적. 리터럴 유형에 대해 생각하지 않았습니다.

@NN---: 귀하의 예가 이미 효과가 있다고 생각합니다.

@tycho01 흐름에는 이제 함수의 반환 유형을 가져오는 $Call 유형이 있습니다. https://github.com/facebook/flow/commit/ac7d9ac68acc555973d495f0a3f1f97758eeedb4

typeof fn(...) 만 허용하는 것은 임의의 표현식에 typeof 를 허용하는 것과 동일하지 않습니까?

function fn() {
  return /** whatever expression you like */;
}
type a = typeof fn();

유형을 파악하는 것 외에 다른 목적으로 런타임 함수를 만들고 있다는 점을 제외하고는?

설마. 표현식의 실행이 아니라 표현식의 유형 평가를 수행하고 있습니다.

@dyst5422 typeof fn() 는 실제로 표현식을 평가하지 않고 리턴 유형만 제공합니다.

편집: 아마도 그것이 당신이 말하려고 했던 것일 수도 있습니다. 확실하지 않습니다. 하지만 @sky87 이 _평가_가 아니라 형식 표현식에서 사용하는 것 외에는 아무 목적 없이 함수 _정의_에 대해 이야기한 것 같습니다.

@dyst5422 , @pelotom 이 말했듯이, 나는 당신이 그 기능을 실행한다는 것을 의미하지 않았습니다. 더 자세히 설명하자면, 임의의 표현식에 typeof 를 허용하지 않고 함수의 반환 유형에 typeof 를 허용하면 더 복잡한 유형을 파악하기 위해 무엇을 할 것입니까? 표현식은 반환 유형을 요청할 수 있도록 함수로 래핑하는 것입니다. 그것은 반환 유형을 얻기 위해 런타임에 함수를 생성하고 작성하기에 더 많은 상용구입니다.

편집: 실제로 임의의 표현식 유형을 이미 파악할 수 있습니다. 이것은 추악하지만 작동합니다.

const dummy = (false as true) && /* arbitrary exp */;
type TypeOfExp = typeof dummy;

솔직히 어떤 해킹을 선호할지 모르겠습니다. typeof 를 사용하여 직접 유형을 요청할 수 있는 것이 가장 좋은 방법이라고 생각합니다.

아, 지금 팔로우하고 있습니다. 네, 다음과 같이 사용할 수 있는 것이 바람직한 방법이라고 생각합니다.

type TypeOfExp = typeof (
  false &
  "false" &
  0
)

표현식 유형 평가를 임의로 수행할 수 있도록

new 호출의 반환 유형을 쿼리할 수 있습니까? 내 사용 사례: PromiseConstructorLike 구현(예: $q 또는 Bluebird)에 대한 참조를 허용하고 해당 구현에 의해 생성된 Promise를 반환하는 함수에 대한 유형 주석을 작성하고 싶습니다.

declare function wait<P extends PromiseConstructorLike>(time: number, implementation: P): typeof new implementation<void>((res: any, rej: any) => void);

const bluebirdPromise = wait(1e3, Bluebird);
// typeof bluebirdPromise should be instance of Bluebird

typeof 없이 반환 유형을 쿼리할 수 있습니까? 아니면 null as FnType 해야 합니까?

interface Fn {
    (a: string): string;
    (a: number): boolean;
}
type Ret = Fn(number); // Ret = boolean
type Ret = typeof (null as Fn)(number);

이 질문에 이미 답변이 되었다면 죄송합니다. 나는 그들을 찾을 수 없습니다.

여기서 new 의 요점은 무엇입니까? 그냥 typeof implementation() 를 원하지 않습니까?

아니요, implementation() 는 유효한 호출이 아니기 때문입니다. PromiseConstructorLike 는 해당 유형 선언에 따라 new 를 통해서만 호출할 수 있습니다. typeof implementation() 는 (typeof implementation)['foobar'] 가 유형 오류인 것처럼 유형 오류입니다.

놀이터 링크

FlowType과 같은 추론 가능한 제네릭 유형을 도입할 수 있습니까? 적어도 함수의 반환 값 유형을 가져오는 문제는 해결할 수 있습니다.

type _ExtractReturn<B, F: (...args: any[]) => B> = B;
type ExtractReturn<F> = _ExtractReturn<*, F>;

@Cryrivers : 해당 접근 방식은 #14400을 참조하세요. 출력 유형이 입력에 따라 달라지는 문제는 실제로 해결되지 않습니다.

함수에 대한 호출이 동적으로 반환하는 것을 암시하기 위해 오늘 다시 이것이 필요하게 되었습니다.

ReturnType<T> 연산자는 TS 2.8의 lib.d.ts 에 추가 되며 조건부 유형으로 구동됩니다.

ReturnType<T> 는 아직 인수 유형에 따른 반환 유형을 고려하지 않았기 때문에 참고로 여기에 Flow의 $Call 유형 구현이 있습니다.

편집: 죄송합니다 @goodmind , 당신이 이미 정확히 그것에 연결되어 있다는 것을 깨닫지 못했습니다.

최근 TS 추가 사항을 기반으로 이 제안(또는 해당 유형 호출 해석)의 사용 사례에 대한 이전 게시물 을 업데이트했습니다.
패턴 일치 사용 사례는 이제 #21496에 의해 다루어지며, ... 사용자가 제공한 람다를 기반으로 유형을 계산하려는 경우(예: curry , 함수 구성, map , reduce )

PS @thorn0 : 이제 Angular 사용 사례를 ReturnType (#21496)로 채울 수 있다고 생각합니다!

이 표현을 허용함으로써 이것을 커버해야 한다고 생각합니다.
prop2: this.prop1.big.complex의 유형;

@mhegazy 이것을 추적하기 위한 별도의 문제가 있습니까?
typeof가 로컬에서는 작동하지만 속성에서는 작동하지 않는 반면 정적 속성에서는 작동하는 것이 짜증납니다.

class A {
    x: number;
    static y: number;
    f() {
        const a: number = 1;
        const b: typeof a = 2; // OK
        const c: this.x = 3; // No :(
        const d: this['x'] = 3; // OK
        const e: typeof A.y = 4 // OK
    }
}

@NN--- 항상 인덱싱된 유형을 사용할 수 있습니다.

this['x']

@cameron-martin 작동하지 않습니다. 운동장

@tycho01 새로운 유형의 추론과 조건은 훌륭하지만 함수 오버로딩에 작동하지 않는다는 점에서 매우 짜증스럽습니다. 주어진 이유는 가능한 것 중에서 함수 유형을 해결하기 위해 이와 같은 typeof 가 필요하기 때문입니다.

@NN 은 const d: this['x'] = 3; 를 사용하세요.

오, 좋아요 :)

@NN--- 또는 사용

class A {
    x: number;
    static y: number;
    f() {
        const self = this;
        const a: number = 1;
        const b: typeof a = 2; // OK
        const c: typeof self.x = 3; // OK
        const d: typeof self['x'] = 3; // OK
        const e: typeof A.y = 4 // OK
    }
}

@tofist 로컬이 작동한다는 것을 알고 있지만 이것은 추악합니다.
암시적 캡처로 람다를 사용하는 대신 'function(){}' 콜백에 대해 'this'를 수동으로 저장하는 것과 같습니다.

@NN

이 못생긴.

네, 이것은 단지 옵션입니다 :)

특정 인수 집합의 유효성을 검사하려는 경우 특정 다른 별칭과 함께 ReturnTypeOf<T> 를 작성할 수 있으므로 조건부 유형은 이제 이것을 크게 관련이 없게 만듭니다. 그들은 과부하 해결을 할 수 없지만 우리는 이 기능이 그 사용 사례에 대한 복잡성만큼 가치가 있다고 생각하지 않습니다.

@RyanCavanaugh ReturnType<T> 말씀하시는 것 같은데요?

@RyanCavanaugh 불행한 일입니다. 과부하 해결이 제가 정말 필요했던 것입니다. 조건부/추론 유형에 과부하 해결을 추가하는 것을 추적하는 또 다른 문제가 있습니까?

다음과 같이 작성할 수 있어야 합니다.

type Return1<A1, T extends (a: A1) => any> = T extends (a: A1) => infer R ? R : any;
type Return2<A1, A2, T extends (a: A1, a: A2) => any> = T extends (a: A1, a: A2) => infer R ? R : any;

declare function something(a: number): number;
declare function something(a: string): string;
declare function something(a: number, b: string): boolean;

type A = Return1<number, something>; // number
type B = Return1<string, something>; // string
type C = Return2<number, string, something>; // boolean

나는 그것을 테스트하지 않았으며 각 인수 수에 대해 별도의 도우미가 필요합니다.

@ForbesLindesay : something 는 현재 표현식 수준 변수입니다. 예를 들어 여기에서 typeof 로 참조하거나 인터페이스로 선언하면 수정됩니다. 나는 실제로 적절한 반환 유형을 산출하도록 관리하고 있지 않습니다( 2.8.0-dev.20180318 ).

@ForbesLindesay 불행히도 나는 그것이 효과가 있다고 믿지 않습니다. 추론 메커니즘은 _last_ 메서드 오버로드를 선택합니다.

type Funcs = ((p1: string, p2: string) => void) & ((p1: number) => void);

type FuncPromise1<T> = T extends (p1: infer P1) => void ? (p1: P1) => Promise<[P1]> : never;
type FuncPromise2<T> = T extends (p1: infer P1, p2: infer P2) => void ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: FuncPromise1<Funcs> & FuncPromise2<Funcs>;

그러나 추론 메커니즘은 튜플 통합을 _is_ 처리할 수 있습니다.

type Tuples = [string, string] | [number];

type TuplePromise1<T> = T extends [infer P1] ?  (p1: P1) => Promise<[P1]> : never;
type TuplePromise2<T> = T extends [infer P1, infer P2] ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: TuplePromise1<Tuples> & TuplePromise2<Tuples>;

오버로드 -> 객체, 함수 -> 객체, 래핑 해제를 허용하는 것이 필요할 수 있습니다. 거기에서 유형 매핑 및 추론을 수행한 다음 함수 및 오버로드로 다시 래핑합니다.

@MeirionHughes :

오버로드 -> 객체, 함수 -> 객체, 래핑 해제를 허용하는 것이 필요할 수 있습니다. 거기에서 유형 매핑 및 추론을 수행한 다음 함수 및 오버로드로 다시 래핑합니다.

(a: number, b?: string) => boolean -> { a: number, b?: string } ? 우리는 아직 그런 매개변수 이름을 얻을 수 없지만 개념적으로 이것은 나머지 매개변수( (a: number, ...b: string[]) => boolean )에 대해 더 어려워집니다. 또한 객체 유형을 사용하여 순서를 지정할 수 없기 때문입니다.

순서는 아마도 이름보다 더 중요하며 매개변수와 튜플 간에 변환할 수 있습니다 . 스프레드/옵션은 여전히 ​​약간 복잡할 수 있습니다.

이것은 과부하를 추출하는 문제를 줄입니다. 오버로드는 ((a: number) => 123) & ((s: string) => 'hi') 와 같은 함수 유형의 교차여야 합니다. 따라서 문제는 교차 유형(예: 튜플 유형으로)을 '포장 해제'하는 방법입니다. 현재로서는 그런 것이 없습니다.

과부하 유스 케이스를 다루지만 제네릭은 말하지 않기 때문에 이 경로가 불만족스럽다는 것을 알았습니다. 하지만 그렇습니다. 교차로 풀기 작업은 여전히 ​​​​어느 쪽이든 갭이었습니다.

이제 이 문제가 종료되었으므로 아직 누락된 부품에 대한 새로운 제안이 있습니까? 인수에 따라 반환 유형을 처리하는 방법과 같은?

이제 이 문제가 종료되었으므로 아직 누락된 부품에 대한 새로운 제안이 있습니까?

내가 알고 있는 것은 없습니다.

인수에 따라 반환 유형을 처리하는 방법과 같은?

통화 유형을 추적하는 데 문제가 있다고 생각하지 않습니다.

유형 수준 기능 응용 프로그램을 추가하는 아이디어에 대한 예비 지원이 있습니까? 나는 그것에 대한 제안을 작성할 수 있습니다. 문법적으로는 그게 가장 쉬운 길이라고 생각합니다.

type MyType<A> = {
    foo: A
}

type Wrap = {
    <T>(maybe: MyType<T>): MyType<T>;
    (maybe: any): MyType<any>;
}

type Naive = ReturnType<Wrap>; // Naive = { foo: any }
type Proposed1 = Wrap(maybe: number); // Proposed1 = { foo: number }
type Proposed2 = Wrap(maybe: MyType<number>); // Proposed2 = { foo: number }
type Proposed3 = (<T>(maybe: T) => MyType<T>)(maybe: number) // Proposed3 = { foo: number }

엣지 케이스:

const foo = <T>(a: T) => T:

type Edge1 = (typeof foo)(a: number) // Probably trivial?

type Foo = {
    <T>(a: string): T
}

type Edge2 = Foo<number>(a: string) // Should this be allowed? Probably not, because:

type Bar<A> = {
    (a: string): A
}

type Edge3 = Bar<number>(a: string) // Things are getting strange

interface Baz<A> {
    <T>(a: T): T | A
}

type Edge4 = Baz<number>(a: string) // What is this?

유형 수준 기능 응용 프로그램을 추가하는 아이디어에 대한 예비 지원이 있습니까? 나는 그것에 대한 제안을 작성할 수 있습니다. 문법적으로는 그게 가장 쉬운 길이라고 생각합니다.

현재로서는 아닙니다. 우리는 고차 유형 공간에 과부하 해결을 넣고 싶지 않습니다. 프로세스는 다소 복잡하며 유형 매개변수를 유추하기 위한 여러 패스와 컨텍스트 형식 인수 등을 포함합니다. 더 높은 순서로 이 작업을 수행하는 것은 먼저 많은 작업이 필요하고 두 번째로 처리할 준비가 되지 않은 성능 문제가 발생합니다. 시간 인.

@mhegazy 는 #24897의 최근 작업을 감안할 때 이에 대한 팀의 입장이 전혀 바뀌지 않았습니까?

$Call 유형으로 솔루션을 축소할 수 있는 몇 가지 문제가 있는 것 같습니다. $Call 유형은 더 높은 종류의 유형을 에뮬레이트하는 비교적 간단한 방법의 문을 열 것입니다. 예를 들어 https://gist.github.com/hallettj/0fde5bd4c3ce5a5f6d50db6236aaa39e 를 참조하십시오( $PropertyType 및 $ObjMap 의 사용을 $Call 로 대체). 편집: 추가 예: https://github.com/facebook/flow/issues/30#issuecomment -346674472

그러한 기능은 틀림없이 많은 문제에 대한 합리적인 공통 솔루션을 찾은 TypeScript의 실적과 일치할 것입니다. 그렇죠?

특정 인수 집합의 유효성을 검사하려는 경우 특정 다른 별칭과 함께 ReturnTypeOf<T> 를 작성할 수 있으므로 조건부 유형은 이제 이것을 크게 관련이 없게 만듭니다. 그들은 과부하 해결을 할 수 없지만 우리는 이 기능이 그 사용 사례에 대한 복잡성만큼 가치가 있다고 생각하지 않습니다.

@RyanCavanaugh @mhegazy

조건부 유형을 사용하여 작업을 수행할 수 있다는 데 동의합니다. User.avatar 를 User extends { avatar: infer T } ? T : never 로 다시 쓴다면 컴파일러에 추가적인 복잡성을 가져오지 않을 것이라고 생각합니다. 예를 들어 다음과 같이 작성할 수 있습니다.

export type Avatar = User extends { avatar: infer T } ? T : never;

같이

export type Avatar = User.avatar;

가독성을 향상시키기 위해.

전체 예

일부 데이터를 로드 및 변환하고 다음과 같은 findUser 함수로 끝난다고 가정합니다.

export function findUser() {
  return {
    username: 'johndoe',
    avatar: {
      lg: '1.jpg',
      s: '2.jpg'
    },
    repos: [
      {
        name: 'ts-demo',
        stats: {
          stars: 42,
          forks: 4
        },
        pull_requests: [
          { date: '2019-08-19', tags: ['bug', 'agreed-to-cla'] },
          { date: '2019-08-10', tags: ['bug', 'includes-tests'] },
          { date: '2019-08-07', tags: ['feature'] }
        ]
      }
    ]
  };
}

매핑된 유형의 추론 덕분에 다음과 같이 함수에서 유형을 추출할 수 있습니다.

export type User = ReturnType<typeof findUser>;
export type Avatar = User extends { avatar: infer T } ? T : never;

제안: 이것은 같은 것으로 평가되어야 합니다.

export type Avatar = User.avatar;

또한 User.avatar 가 never 유형이 아니어야 한다고 주장할 수도 있습니다.

더 많은 예

export type Repositories = User extends { repos: infer T } ? T : never;
export type Repository = User extends { repos: (infer T)[] } ? T : never;
export type RepositoryStats = Repository extends { stats: infer T } ? T : never;
export type PullRequests = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type PullRequest = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type Tags = PullRequest extends { tags: infer T } ? T : never;
export type Tag = PullRequest extends { tags: (infer T)[] } ? T : never;

export type Repositories = User.repos;
export type Repository = User.repos[];
export type RepositoryStats = User.repos[].stats;
export type PullRequests = User.repos[].pull_requests;
export type PullRequest = User.repos[].pull_requests[];
export type Tags = User.repos[].pull_requests[].tags;
export type Tag = User.repos[].pull_requests[].tags[];

중첩 속성을 한 번에 매핑할 때 무슨 일이 일어나고 있는지 명확하지 않습니다.

export type Tag2 = User extends { repos: { pull_requests: { tags: (infer T)[] }[] }[] } ? T : never;

이것은 많은 것을 밝힐 것입니다.

export type Tag = User.repos[].pull_requests[].tags[];

코너 케이스

export class Hello {
  static world = 'world';
  world = 42;
}

export type ThisWillBeANumber = Hello extends { world: infer T } ? T : never;
export type ThisWillBeANumber = Hello.world;

export type ThisWillBeAString = (typeof Hello) extends { world: infer T } ? T : never;
export type ThisWillBeAString = (typeof Hello).world;

@lukaselmer 그냥 원하는 것 같습니다

export type Avatar = User["avatar"];

오늘 작동하는

@lukaselmer 그냥 원하는 것 같습니다

export type Avatar = User["avatar"];

오늘 작동하는

그것이 바로 내가 찾던 것입니다. 문서 에서 검색했지만 찾지 못했습니다. 감사합니다!

이것은 핸드북의 일부입니까, 아니면 이것이 어떻게 작동하는지에 대한 공식 문서가 있습니까? 나는 그것을 사용하는 방법에 대해 꽤 익숙하지만 사람들을 문서로 안내하려고 할 때 내가 찾을 수 있는 것은 typeof 가드뿐이며 이는 정말 완전히 다릅니다.

그래서 저는 이 제안이 2015년부터 튕겨져 나왔고 원래 목표 중 하나는 인터페이스의 단일 속성 유형을 얻는 것이었음을 알게 되었습니다.

interface a {
 foo: bar;
 /* more types */
}

const example = (fooNeeded: [magic] a.foo ) => {};

이것이 5년 후에도 여전히 불가능하다고 가정하는 것이 맞습니까?

@MFry 다음 구문을 찾고 있다고 생각합니다. a['foo']

이에 대한 해결책이 아직 있는지 알고 있습니까?

나는 다음과 같은 것을 얻으려고 노력 중이다.

declare function something<A, B>(): void;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<T extends ReturnType<typeof something>>(arg: T): { payload: unknown };

doThing(hello).payload === 123; // this should validate to a string aka type Payload

https://www.typescriptlang.org/play/index.html?ts=4.0.0-dev.20200512#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwGccBbEDACy1QHMAeAQQBp4AhAPgAoBKALngDccWYAG4AUGIwBPAA4IAClCkQcUYPAC8hDDCrVxYsHgIZ45EBBWbCJMpRq0A3gF9mi5auCcuB0JFgIKOjYePDAOAAq9nQR8CAAHhggqMAE8ABKZMgwqBGyILTScjiINqQUemycsNR8EbzwjvAySipqfGgA1qg4AO74zr6R0RzmljhcAHQtHmqaGloAjABMAMwi8AD0m -AVaQTkOMgQ6vxQEMJQSbs48FDaujR3nfdFCq2eYkA

안녕하세요 @maraisr 당신이 달성하려는 것이 100% 확실하지 않습니다. 귀하의 예에서 something 는 두 가지 유형을 사용하지만 사용하지 않습니다 hello 는 항상 void 가 될 것의 반환 값입니다. 따라서 doThing $는 어떤 시점에서도 string 유형을 보지 않습니다.

아마도 아래와 같은 것이 당신이 원하는 것입니까?

declare function something<ReturnType>(): ReturnType;

type Payload = string;

const hello = () => something<Payload>();

declare function doThing<F extends () => any>(f: F): { payload: ReturnType<F> };

doThing(hello).payload === 'a string';

아 예 - 죄송합니다. 신속한 답변 감사합니다!! :100: @acutmore

void 는 해당 함수의 반환 유형이 관련이 없음을 나타내기 위한 것입니다. 이 2가지 유형은 다른 제네릭 유형으로 전달되어 궁극적으로 인수에 사용됩니다.

다음과 같은 것:

declare function something<A, B>(a: MyComplexGeneric<A>, b: B[]): { somethingA: number, somethingB: number };

// Those 2 generics influence the return object so they do get used as such. And the 2 arguments are roughly that. Its an object and an array, more-or-less. 

내 doThing 함수는 첫 번째( A ) 제네릭이 무엇인지 실제로 신경 쓰지 않지만 두 번째( B )가 무엇인지는 상관합니다.

내 자신의 사용 사례에서 something 가 doThing 에서 읽을 수 있는 부작용을 수행하는 것을 확인하십시오.

따라서 단순히 함수의 ReturnType을 가져올 수 없습니다. 생성된 함수의 제네릭을 어떻게든 빨아들여야 합니다.

이 쿼리가 이 문제의 범위를 벗어났다고 생각되면 StackOverflow에 대한 내 여정을 계속하십시오!

@maraisr 추가 정보 감사합니다.

doThing 에서 something 에서 원래의 B 유형을 가져오려면 어떻게든 hello 에 전달해야 합니다. TypeScript는 hello 만 보고 있으며 도움이 없으면 something 의 반환 유형인지 알지 못합니다.

이것이 가능한 한 가지 방법입니다.

/** Create a type that can store some extra type information **/
interface SomethingResult<T> {
    __$$__: T;
    somethingA: number;
    somethingB: number;
}

declare function something<A, B>(): SomethingResult<B>;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<Result extends SomethingResult<any>>(arg: Result): { payload: Result['__$$__'] };

doThing(hello).payload === 1123; // error because `payload` is of type string

interface User {
  avatar: string;
}

interface UserData {
  someAvatar: User['avatar'];
}

@RyanCavanaugh 왜 닫혀있나요? 조건부 유형은 이 문제와 다른 많은 사용 사례를 해결하지 못하며 이것이 병합되면 많은 일이 가능해집니다.

저는 모든 메서드 호출을 "포인트 없는" 버전으로 전환할 수 있는 함수를 작업 중입니다(예: [].map(() => n > 5) 가 map(() => n > 5)([]) 로 바뀌고 누락된 유일한 것은 조건부 유형 및 infer 는 제네릭을 감지할 수 없으므로 제네릭 함수에서 일부 유형은 unknown 로 나옵니다.

함수를 "호출"하여 유형( typeof myFunc(() => Either<string,number>) )을 가져올 수 있다면 이 기능을 가질 수 있고(현재는 불가능), 다른 많은 작업을 훨씬 더 쉽게 수행할 수 있습니다(HKT 등). .)

$Call 함수(예: 흐름)를 수행할 수 있는 복잡성이 매우 높습니까? typescript가 이미 자동으로 수행하는 것처럼 느껴집니다.

@nythrox 우리는 이것이 초래할 수 있는 구문론적 혼란이 어떤 유형에 도달하기 위해 필요한 경우보다 중요하다고 생각하지 않습니다. 호출 표현식을 해결하는 특정 사례는 다른 곳에서 추적됩니다. "어떤 표현이든 허용하라"는 OP의 제안은 우리가 생각하기에 언어에 적합하지 않을 것입니다.

@RyanCavanaugh 아, 알겠습니다. 응답해 주셔서 감사합니다. 함수 호출을 해결하는 동안 어떤 문제가 추적되는지 알고 있습니까?

나는 약간의 주위를 검색했고 함수 호출 유틸리티 유형에 대한 문제를 찾지 못했습니다. 내가 찾은 유일한 참조는 #20352에 있었는데, 이 문제는 이 문제에 다시 연결되었습니다.

호출 표현식을 해결하는 특정 사례는 다른 곳에서 추적됩니다.

@RyanCavanaugh 다른 곳과 연결되는 것을 염두에 두시겠습니까? 🙂

@tjjfvi #37181은 더 구체적으로 입력을 기반으로 함수를 해결하는 것에 관한 것입니다. 당신이 찾고있는 것일 수 있습니다.

@acutmore 흐름과 유사한 $Call 유틸리티 또는 이를 구현할 수 있는 다른 구문에 대해 구체적으로 이야기하고 있었지만 그것은 내가 찾고 있던 것과 다소 일치합니다. 접근 방식이 이상하다고 제안했지만 링크에 감사드립니다.