Typescript: 제안: 정규식으로 검증된 문자열 유형

예, 나는 이것을 확실히 Typed를 통해 빗질하는 것을 보았습니다. 서비스 계층에서 이와 같은 것을

주요 문제는 다음과 같습니다.

• 이것들을 잘 구성하는 방법은 명확하지 않습니다. "cat" , "dog" 및 "fish" 의 쉼표로 구분된 목록을 원하면 /dog|cat|fish(,(dog|cat|fish))*/ 와 같이 작성해야 합니다.
  
  
  
  • "cat" , "dog " 및 "fish" 대한 문자열 리터럴 유형을 설명하는 유형이 이미 있는 경우 이 정규식에 어떻게 통합합니까?
  
  
  • 분명히 여기에는 바람직하지 않은 반복이 있습니다. 아마도 이전 문제를 수정하면 이 작업이 더 쉬워질 것입니다.
  
  
• 비표준 확장은 이런 종류의 iffy를 만듭니다.

이에 대한 엄청난 +1, ZipCode, SSN, ONet 및 이에 대한 다른 많은 사용 사례.

나는 같은 문제에 직면했고 아직 구현되지 않았으며 아마도 이 해결 방법이 도움이 될 것입니다.
http://stackoverflow.com/questions/37144672/guid-uuid-type-in-typescript

@mhegazy가 제안한 대로 여기에 내 제안(#8665)을 넣을 것입니다. 형식 선언에서 간단한 유효성 검사 기능을 허용하는 것은 어떻습니까? 그런 것 :

type Integer(n:number) => String(n).macth(/^[0-9]+$/)
let x:Integer = 3 //OK
let y:Integer = 3.6 //wrong

type ColorLevel(n:number) => n>0 && n<= 255
type RGB = {red:ColorLevel, green:ColorLevel, blue:ColorLevel};
let redColor:RGB = {red:255, green:0, blue:0}   //OK
let wrongColor:RGB = {red:255, green:900, blue:0} //wrong

type Hex(n:string) => n.match(/^([0-9]|[A-F])+$/)
let hexValue:Hex = "F6A5" //OK
let wrongHexValue:Hex = "F6AZ5" //wrong

유형이 허용할 수 있는 값은 함수 매개변수 유형과 함수 평가 자체에 의해 결정됩니다. 그러면 #7982도 해결됩니다.

@rylphs +1 이것은 TypeScript를 매우 강력하게 만듭니다.

하위 유형은 _regex로 검증된 문자열 유형_과 어떻게 작동합니까?

let a: RegExType_1
let b: RegExType_2

a = b // Is this allowed? Is RegExType_2 subtype of RegExType_1?
b = a // Is this allowed? Is RegExType_1 subtype of RegExType_2?

여기서 RegExType_1 및 RegExType_2 는 _regex로 검증된 문자열 유형_입니다.

편집: 이 문제는 다항식 시간에 해결할 수 있는 것 같습니다( 정규 표현식에 대한 포함 문제 참조).

TypeStyle에도 도움이 됩니다: https://github.com/typestyle/typestyle/issues/5 :rose:

JSX에서 @RyanCavanaugh 와 저는 사람들이 aria- (및 잠재적으로 data- ) 속성을 추가하는 것을 보았습니다. 실제로 누군가가 완전 형식으로 ConfirmTyped에 문자열 인덱스 서명을 추가했습니다. 이에 대한 새로운 색인 서명이 도움이 될 것입니다.

interface IntrinsicElements {
    // ....
    [attributeName: /aria-\w+/]: number | string | boolean;
}

디자인 제안

개발자가 문자열보다 더 많은 지정된 값이 필요하지만 CSS 색상, 이메일, 전화 번호, ZipCode, swagger 확장 등과 같은 단순한 문자열 리터럴의 조합으로 열거할 수 없는 경우가 많습니다. 일반적으로 json 스키마 사양도 JSON 개체의 스키마를 설명하는 데 사용되는 패턴 및 patternProperties 는 TS 유형 시스템 측면에서 regex-validated string type 및 regex-validated string type of index 라고 할 수 있습니다.

목표

개발자가 일반적으로 사용하는 JSON 스키마에 한 걸음 더 가까운 유형 시스템을 제공하고 필요할 때 문자열 유효성 검사를 잊어버리지 않도록 합니다.

구문 개요

이 기능의 구현은 4가지 부분으로 구성됩니다.

정규식 검증 유형

type CssColor = /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;

type Email = /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i;

type Gmail = /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@gmail\.com$/i;

정규식 검증 변수 유형

let fontColor: /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;

동일하지만 더 읽기 쉽습니다.

let fontColor: CssColor;

인덱스의 정규식 검증 변수 유형

interface UsersCollection {
    [email: /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i]: User;
}

동일하지만 더 읽기 쉽습니다.

interface UsersCollection {
    [email: Email]: User;
}

가변형 타입 가드

setFontColorFromString(color: string) {
    fontColor = color;// compile time error
    if (/^#([0-9a-f]{3}|[0-9a-f]{6})$/i.test(color)) {
        fontColor = color;// correct
    }
}

그리고 같은

setFontColorFromString(color: string) {
    fontColor = color;// compile time error
    if (!(/^#([0-9a-f]{3}|[0-9a-f]{6})$/i.test(color))) return;
    fontColor = color;// correct
}

더 나은 가독성을 위해 정의된 유형 사용

setFontColorFromString(color: string) {
    fontColor = color;// compile time error
    if (CssColor.test(color)) {
        fontColor = color;// correct
    }
}

같은

setFontColorFromString(color: string) {
    fontColor = color;// compile time error
    if (!(CssColor.test(color))) return;
    fontColor = color;// correct
}

인덱스 유형에 대한 유형 가드

let collection: UsersCollection;
getUserByEmail(email: string) {
    collection[email];// type is any
    if (/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i.test(email)) {
        collection[email];// type is User
    }
}

같은

let collection: UsersCollection;
getUserByEmail(email: string) {
    collection[email];// type is any
    if (!(/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i.test(email))) return;
    collection[email];// type is User
}

더 나은 가독성을 위해 정의된 유형 사용

let collection: UsersCollection;
getUserByEmail(email: string) {
    collection[email];// type is any
    if (Email.test(email)) {
        collection[email];// type is User
    }
}

같은

let collection: UsersCollection;
getUserByEmail(email: string) {
    collection[email];// type is any
    if (!(Email.test(email))) return;
    collection[email];// type is User
}

시맨틱 개요

과제

let email: Email;
let gmail: Gmail;
email = '[email protected]';// correct
email = '[email protected]';// correct
gmail = '[email protected]';// compile time error
gmail = '[email protected]';// correct
gmail = email;// obviously compile time error
email = gmail;// unfortunately compile time error too

불행히도 우리는 이 문서 로 인해 심각한 성능 영향 없이 한 정규식이 다른 정규식의 하위 유형인지 확인할 수 없습니다. 그래서 제한해야 합니다. 그러나 다음 해결 방법이 있습니다.

// explicit cast
gmail = <Gmail>email;// correct
// type guard
if (Gmail.test(email)) {
    gmail = email;// correct
}
// another regex subtype declaration
type Gmail = Email & /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@gmail\.com$/i;
gmail = email;// correct

불행히도 string 변수를 regex-validated 변수에 할당하는 것도 제한되어야 합니다. 컴파일 시간에 정규식과 일치한다는 보장이 없기 때문입니다.

let someEmail = '[email protected]';
let someGmail = '[email protected]';
email = someEmail;// compile time error
gmail = someGmail;// compile time error

그러나 여기에 표시된 대로 명시적 캐스트 또는 유형 가드를 사용할 수
운 좋게도 문자열 리터럴의 경우는 아닙니다. 문자열 리터럴을 사용하는 동안 해당 값이 정규식과 일치하는지 확인할 수 있기 때문입니다.

let someEmail: '[email protected]' = '[email protected]';
let someGmail: '[email protected]' = '[email protected]';
email = someEmail;// correct
gmail = someGmail;// correct

인덱스의 유형 축소

regex-validated type 인덱스의 간단한 경우는 인덱스 유형에 대한 유형 보호를 참조하십시오.
그러나 더 복잡한 경우가 있을 수 있습니다.

type Email = /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i;

type Gmail = /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@gmail\.com$/i;

interface UsersCollection {
    [email: Email]: User;
    [gmail: Gmail]: GmailUser;
}
let collection: UsersCollection;
let someEmail = '[email protected]';
let someGmail = '[email protected]';
collection['[email protected]'];// type is User
collection['[email protected]'];// type is User & GmailUser
collection[someEmail];// unfortunately type is any
collection[someGmail];// unfortunately type is any
// explicit cast is still an unsafe workaround
collection[<Email> someEmail];// type is User
collection[<Gmail> someGmail];// type is GmailUser
collection[<Email & Gmail> someGmail];// type is User & GmailUser

리터럴에는 그런 문제가 없습니다.

let collection: UsersCollection;
let someEmail: '[email protected]' = '[email protected]';
let someGmail: '[email protected]' = '[email protected]';
collection[someEmail];// type is User
collection[someGmail];// type is User & GmailUser

그러나 변수의 경우 가장 좋은 옵션은 다음보다 현실적인 예에서와 같이 유형 가드를 사용하는 것입니다.

getUserByEmail(email: string) {
    collection[email];// type is any
    if (Email.test(email)) {
        collection[email];// type is User
        if (Gmail.test(email)) {
            collection[email];// type is User & GmailUser
        }
    }
    if (Gmail.test(email)) {
        collection[email];// type is GmailUser
    }
}

그러나 Gmail 유형에 대해 더 나은 정의를 사용하면 다른 유형이 축소됩니다.

type Gmail = Email & /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@gmail\.com$/i;

getUserByEmail(email: string) {
    collection[email];// type is any
    if (Email.test(email)) {
        collection[email];// type is User
        if (Gmail.test(email)) {
            collection[email];// type is User & GmailUser
        }
    }
    if (Gmail.test(email)) {
        collection[email];// type is User & GmailUser
    }
}

조합 및 교차로

실제로 일반적인 유형과 regex-validated 유형은 실제로 다르기 때문에 합집합과 교차를 올바르게 처리하는 규칙이 필요합니다.

type Regex_1 = / ... /;
type Regex_2 = / ... /;
type NonRegex = { ... };
type test_1 = Regex_1 | Regex_2;// correct
type test_2 = Regex_1 & Regex_2;// correct
type test_3 = Regex_1 | NonRegex;// correct
type test_4 = Regex_1 & NonRegex;// compile time error
if (test_1.test(something)) {
    something;// type is test_1
    // something matches Regex_1 OR Regex_2
}
if (test_2.test(something)) {
    something;// type is test_2
    // something matches Regex_1 AND Regex_2
}
if (test_3.test(something)) {
    something;// type is Regex_1
} else {
    something;// type is NonRegex
}

제네릭

제네릭에는 특별한 경우가 없으므로 regex-validated type은 일반 타입과 같은 방식으로 제네릭과 함께 사용할 수 있습니다.
아래와 같은 제약 조건이 있는 제네릭의 경우 regex-validated 유형은 문자열처럼 작동합니다.

class Something<T extends String> { ... }
let something = new Something<Email>();// correct

개요 방출

일반적인 유형과 달리 regex-validated 는 방출에 약간의 영향을 미칩니다.

type Regex_1 = / ... /;
type Regex_2 = / ... /;
type NonRegex = { ... };
type test_1 = Regex_1 | Regex_2;
type test_2 = Regex_1 & Regex_2;
type test_3 = Regex_1 | NonRegex;
type test_4 = Regex_1 & NonRegex;
if (test_1.test(something)) {
    /* ... */
}
if (test_2.test(something)) {
    /* ... */
}
if (test_3.test(something)) {
    /* ... */
} else {
    /* ... */
}

다음으로 컴파일됩니다.

var Regex_1 = / ... /;
var Regex_2 = / ... /;
if (Regex_1.test(something) || Regex_2.test(something)) {
    /* ... */
}
if (Regex_1.test(something) && Regex_2.test(something)) {
    /* ... */
}
if (Regex_1.test(something)) {
    /* ... */
} else {
    /* ... */
}

호환성 개요

이 기능은 호환성에 문제가 없습니다. 왜냐하면 그것을 깨뜨릴 수 있는 경우만 있고 regex-validated 유형이 일반 유형과 달리 영향을 방출하기 때문이므로 유효한 TS 코드입니다.

type someType = { ... };
var someType = { ... };

아래 코드가 아닌 경우:

type someRegex = / ... /;
var someRegex = { ... };

그러나 두 번째는 이미 유효하지 않지만 다른 이유로 인해(유형 선언이 잘못되었습니다).
따라서 이제 이 유형이 regex-validated 경우를 대비하여 유형과 동일한 이름을 가진 변수 선언을 제한해야 합니다.

추신

제가 놓쳤을 수도 있는 부분을 자유롭게 지적해 주세요. 이 제안이 마음에 들면 이를 다루는 테스트를 만들고 PR로 추가할 수 있습니다.

regex-validated 유형의 교차 및 합집합에 대한 몇 가지 사례를 지적하는 것을 잊었지만 최신 테스트 사례에서 설명했습니다. 그 사소한 변경 사항을 반영하기 위해 Design proposal 를 업데이트해야 합니까?

@Igmat , 디자인 제안에 대한 질문: 방출 개요에 대해 자세히

@alexanderbird 예, 다른 유형은 방출에 영향을 미치지 않습니다. 처음에는 regex-validated 도 그렇게 할 것이라고 생각했기 때문에 제안서를 만들고 제안된 구문을 사용하기 시작했습니다.
첫 번째 접근 방식은 다음과 같습니다.

let fontColor: /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;
fontColor = "#000";

이:

type CssColor: /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;
let fontColor: CssColor;
fontColor = "#000";

"#000" 는 컴파일 시간에 확인할 수 있기 때문에 괜찮고 변경 사항을 내보낼 필요가 없습니다.
그러나 우리는 또한 그것을 유용하게 만들기 위해 string 에서 regex-validated 유형으로 좁히는 것을 처리해야 합니다. 그래서 저는 이전의 두 가지 설정에 대해 다음과 같이 생각했습니다.

let someString: string;
if (/^#([0-9a-f]{3}|[0-9a-f]{6})$/i.test(someString)) {
    fontColor = someString; // Ok
}
fontColor = someString; // compile time error

따라서 정규 표현식이 잘 읽히지 않고 모든 위치에서 복사되어야 하므로 사용자가 쉽게 실수할 수 있다는 점을 제외하고는 방출에 영향을 미치지 않고 괜찮아 보입니다. 그러나 이 특별한 경우에는 type 작동 방식을 변경하는 것보다 여전히 나은 것 같습니다.
그러나 나는 이 물건이 다음과 같은 것을 깨달았습니다.

let someString: string;
let email: /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/I;
if (/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i.test(someString)) {
    email = someString; // Ok
}
email = someString; // compile time error

악몽이다. 그리고 그것은 교차와 결합이 없는 경우에도 마찬가지입니다. 따라서 이와 같은 일이 발생하지 않도록 하려면 제안에 표시된 대로 type emission을 약간 변경해야 합니다.

@DanielRosenwasser , 이 제안에 대한 피드백을 제공해 주시겠습니까? 그리고 가능하다면 여기에 언급된 테스트에 대해서도 마찬가지입니까?
난 정말이 기능을 구현하는 도움말을 원하지만 그것은 많은 시간을 필요로한다 ( tsc 정말 프로젝트를 복잡하고 나는 여전히 내부 작동 방식의 이해에 일해야) 나는 알고있다하지 않습니다 이 제안은 구현할 준비가 되었습니다. 그렇지 않으면 다른 언어 디자인 비전이나 다른 이유로 인해 이러한 방식으로 구현된 이 기능을 거부할 것입니다.

Hey @Igmat , 처음에 물어

시작하기 위해 나는 여전히 방출하기 위해 어떤 종류의 변경이 필요한지 이해하지 못하며 유형을 기반으로 한 어떤 종류의 방출도 허용되지 않을 것이라고 생각합니다. 여기에서 비목표를 확인

내가 제기했어야 하는 또 다른 문제는 역참조를 사용하는 정규식 문제입니다. 내 이해(및 경험)는 정규식의 역참조가 입력에 지수적인 시간에 테스트를 실행하도록 강제할 수 있다는 것입니다. 코너케이스인가요? 아마도, 하지만 일반적으로 피하고 싶은 것입니다. 이것은 편집기 시나리오에서 위치에서 유형 검사에 최소한의 시간이 소요되어야 한다는 점을 감안할 때 특히 중요합니다.

또 다른 문제는 TypeScript 컴파일러가 실행되는 엔진에 의존하거나 이러한 작업을 실행하기 위해 사용자 지정 정규식 엔진을 빌드해야 한다는 것입니다. 예를 들어, TC39는 . 가 개행과 일치할 수 있도록 새로운 s 플래그를 포함하도록 이동하고 있습니다. ESXXXX와 이를 지원하는 이전 런타임 간에 불일치가 있을 수 있습니다.

@igmat - @DanielRosenwasser 의 말에

그러나 우리는 또한 그것을 유용하게 만들기 위해 문자열에서 정규식 검증 유형으로 좁히는 것을 처리해야 합니다.

동적 문자열에서 정규식 유효성 검사 유형으로 범위를 좁힐 경우에만 해당됩니다. 이것은 매우 복잡해집니다. 이 간단한 경우에도:

function foo(bar: number) {
    let baz: /prefix:\d+/ = 'prefix:' + number;
}

유형이 일치하는지 확신할 수 없습니다. 숫자가 음수이면 어떻게 될까요? 그리고 정규식이 더 복잡해지면 점점 더 복잡해집니다. 우리가 이것을 정말로 원했다면 아마도 "type interpolation: type Baz = /prefix:{number}/ ...를 허용할 것입니다. 하지만 거기에 갈 가치가 있는지 모르겠습니다.

대신, 정규식으로 검증된 유형에 문자열 리터럴만 할당하도록 허용하면 목표에 어느 정도 도달할 수 있습니다.

다음을 고려하세요:

type Color = /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;
let foo: Color = '#000000';
let bar: Color = '#0000'; // Error - string literal '#0000' is not assignable to type 'Color'; '#0000' does not match /^#([0-9a-f]{3}|[0-9a-f]{6})$/i
let baz: Color = '#' + config.userColorChoice; // Error - type 'string' is not assignable to type 'regex-validated-string'

실행 가능한 대안이라고 생각하십니까?

@DanielRosenwasser , 나는 Design Goals를 주의 깊게 읽었고 , 내가 당신을 올바르게 이해한다면 문제는 Non-goals#5 위반입니다.
그러나 그것은 위반이 아니라 구문 개선으로 보입니다. 예를 들어 이전에는 다음이 있었습니다.

const emailRegex = /.../;
/**
 * assign it only with values tested to emailRegex 
 */
let email: string;
let userInput: string;
// somehow get user input
if (emailRegex.test(userInput)) {
    email = userInput;
} else {
    console.log('User provided invalid email. Showing validation error');
    // Some code for validation error
}

이 제안을 구현하면 다음과 같이 보일 것입니다.

type Email = /.../;
let email: Email;
let userInput: string;
// somehow get user input
if (Email.test(userInput)) {
    email = userInput;
} else {
    console.log('User provided invalid email. Showing validation error');
    // Some code for validation error
}

보시다시피 코드는 거의 동일합니다. 정규식의 일반적인 간단한 사용법입니다. 그러나 두 번째 경우는 훨씬 더 표현적이고 정규식 유효성 검사를 의미하는 변수에 할당하기 전에 문자열을 확인하는 것을 잊는 것과 같이 사용자가 실수로 실수하는 것을 방지합니다.
두 번째는 이러한 유형 축소 없이는 일반적으로 인덱스에서 정규식 유효성 검사 유형을 사용할 수 없다는 것입니다. 대부분의 경우 이러한 인덱스 필드는 리터럴로 수행할 수 있기 때문에 런타임에 확인할 수 없는 일부 변수와 함께 작동하기 때문입니다. .

@alexanderbird , 이 코드를 유효하게 만들거나 런타임과 컴파일 시간 모두에 숨겨진 검사를 추가하지 않는 것이 좋습니다.

function foo(bar: number) {
    let baz: /prefix:\d+/ = 'prefix:' + number;
}

이 코드는 내 제안으로 인해 오류를 발생시켜야 합니다. 하지만 이것은:

function foo(bar: number) {
    let baz: /prefix:\d+/ = ('prefix:' + number) as /prefix:\d+/;
}

아니면 이거:

function foo(bar: number) {
    let baz: /prefix:\d+/;
    let possibleBaz: string = 'prefix:' + number;
    if (/prefix:\d+/.test(possibleBaz)) {
        baz = possibleBaz;
    }
}

정확하고 방출된 코드에 영향을 미치지 않습니다.

그리고 이전 댓글에서 보여드린 것처럼 리터럴은 일반적인 사용 사례에서도 확실히 충분하지 않을 것입니다. 왜냐하면 우리는 종종 사용자 입력이나 다른 소스의 스팅으로 작업해야 하기 때문입니다. 이 방출 영향을 구현하지 않으면 사용자는 다음 방법으로 이 유형으로 작업해야 합니다.

export type Email = /.../;
export const Email = /.../;
let email: Email;
let userInput: string;
// somehow get user input
if (Email.test(userInput)) {
    email = <Email>userInput;
} else {
    console.log('User provided invalid email. Showing validation error');
    // Some code for validation error
}

또는 교차로의 경우:

export type Email = /email-regex/;
export const Email = /email-regex/;
export type Gmail = Email & /gmail-regex/;
export const Gmail = {
    test: (input: string) => Email.test(input) && /gmail-regex/.test(input)
};
let gmail: Gmail;
let userInput: string;
// somehow get user input
if (Gmail.test(userInput)) {
    gmail = <Gmail>userInput;
} else {
    console.log('User provided invalid gmail. Showing validation error');
    // Some code for validation error
}

컴파일러에서 쉽게 처리할 수 있을 때 사용자에게 코드를 복제하고 명시적 캐스트를 사용하도록 강요하는 것은 좋은 방법이 아니라고 생각합니다. 방출 영향은 정말 매우 작고 예측 가능합니다. 방출 변경 없이 이 기능을 구현하는 동안 사용자를 놀라게 하거나 일부 기능을 잘못 이해하거나 찾기 어려운 버그로 이어지지 않을 것이라고 확신합니다.

결론적으로 regex-validated 유형은 범위 변수이자 컴파일러 유형이라는 간단한 용어로 말하고 싶습니다.

@DanielRosenwasser 및 @alexanderbird 좋습니다. 이에 대한 아이디어가 하나 더 있습니다. 다음과 같은 구문은 어떻습니까?

const type Email = /email-regex/;

이 경우 사용자는 이것을 type 및 const 둘 다로 원한다고 명시적으로 정의해야 하므로 실제 유형 시스템은 그러한 수정자와 함께 사용되지 않는 한 방출 변경 사항이 없습니다. 그러나 그것과 함께 사용한다면 다음과 같이 동일한 방출을 추가하여 많은 실수, 캐스트 및 코드 복제를 피할 수 있습니다.

const Email = /email-regex/;

이것은 아마도 다음과 같은 것을 허용할 수 있기 때문에 이 제안에 대한 단순한 개선보다 훨씬 더 큰 것 같습니다(예: Redux 가 있는 프로젝트에서 가져온 것):

export type SOME_ACTION = 'SOME_ACTION';
export const SOME_ACTION = 'SOME_ACTION' as SOME_ACTION;

로 변환 중

export const type SOME_ACTION = 'SOME_ACTION';

비슷한 제안을 찾으려고 했지만 성공하지 못했습니다. 해결 방법이 될 수 있고 그러한 아이디어가 마음에 들면 디자인 제안 및 테스트를 준비할 수 있습니다.

@DanielRosenwasser , 두 번째 문제에 대해 - 내 제안에서 컴파일러는 리터럴에 대해서만 정규식을 실행하고 누군가가 다음과 같이 할 것 같지 않기 때문에 그런 일이 일어날 것이라고 생각하지 않습니다.

let something: /some-regex-with-backreferences/ = `
long enough string to make regex.test significantly affect performance
`

어쨌든 우리는 실시간 성능에 영향을 미치기 위해 리터럴이 얼마나 오래 지속되어야 하는지 테스트할 수 있고 사용자가 일부 편집기 시나리오에서 이러한 상황에 직면하는 동안 확인할 수 없는 경우 사용자에게 경고하는 몇 가지 경험적 방법을 만들 수 있지만 그가 컴파일할 때 확인할 것입니다. 프로젝트. 또는 다른 해결 방법이 있을 수 있습니다.

세 번째 질문에 대해 모든 것을 올바르게 이해했는지 확실하지 않지만 구현이 다른 경우 target from tsconfig 에 따라 정규식 엔진을 선택해야 할 것 같습니다. 좀 더 조사가 필요합니다.

@DanielRosenwass 어떤 생각이 있습니까? 😄 초기 제안과 마지막 제안에 대해. 두 번째에 대해 더 자세한 개요를 작성해야 할 수 있습니까?

@Igmat 귀하의 제안은 유효성 검사를 문자열 유형에서만 유용하도록 제한합니다. @rylphs 제안에 대해 어떻게 생각하세요? 이렇게 하면 모든 기본 유형에 대해 보다 일반적인 유효성 검사가 가능합니다.

type ColorLevel = (n:number) => n>0 && n<= 255
type RGB = {red:ColorLevel, green:ColorLevel, blue:ColorLevel};
let redColor:RGB = {red:255, green:0, blue:0}   //OK
let wrongColor:RGB = {red:255, green:900, blue:0} //wrong

그러나 나는 이 메커니즘을 기본형을 넘어 기본형이 아닌 유형으로 확장하는 것이 너무 많을 것이라고 생각합니다.
한 가지 점은 @DanielRosenwasser 가 다양한 정규식 엔진 구현에 대해 제기한 문제가

@zspitz 유망해 보이지만 제 생각에는 컴파일러 성능에 너무 많은 영향을 미칠 수 있습니다. 기능이 규칙에 의해 제한되지 않고 TS가 너무 복잡하거나 사용할 수 없는 일부 리소스에 의존하는 일부 표현식을 계산해야 하기 때문입니다. 컴파일 시간에.

@이그마트

기능이 어떤 규칙에 의해 제한되지 않기 때문에

염두에 둔 몇 가지 구체적인 예가 있습니까? 아마도 유효성 검사 구문을 Typescript의 "안전한"/컴파일 시 알려진 하위 집합으로 제한할 수 있습니다.

사용자 정의 유형 가드가 새로운 유형을 정의하도록 하는 것은 어떻습니까?

// type guard that introduces new nominal type int
function isInt(value: number): value is type int { return /^\d+$/.test(value.toString()); }
// -------------------------------------^^^^ add type keyword here
function printNum(value: number) { console.log(value); }
function printInt(value: int) { console.log(value); }
const num = 123;
printNum(num); // ok
printInt(num); // error
if (isInt(num)) {
    printNum(num); // ok
    printInt(num); // ok
}

@disjukr 은 좋아 보이지만 유형 확장은 어떻습니까?

확장 가능해야 합니까? 그것을 요구하는 TypeScript 디자인 원칙이 있습니까? 그렇지 않은 경우 확장 가능하지 않더라도 @disjukr이 제안하는 명목 유형을 사용하는

확장성 IMHO를 얻으려면 꽤 창의적인 것이 필요합니다. 하나의 임의 유형 가드(함수)가 다른 임의 유형 가드의 하위 집합인지 여부를 결정할 수 없습니다.

유형 주장 사고 방식을 사용하여 기본적인 "확장성"을 얻을 수 있습니다.

function isInt(value: number): value is type int { return /^\d+$/.test(value.toString()); }
// assert that biggerInt extends int. No compiler or runtime check that it actually does extend.
function isBiggerInt(value: number): value is type biggerInt extends int { return /^\d{6,}$/.test(value.toString()); }
// -----------------------------------------------------------^^^^ type extension assertion
function printNum(value: number) { console.log(value); }
function printInt(value: int) { console.log(value); }
function printBiggerInt(value: biggerInt) {console.log(value); }

const num = 123;
printNum(num); // ok
printInt(num); // error
printBiggerInt(num); // error
if (isInt(num)) {
    printNum(num); // ok
    printInt(num); // ok
    printBiggerInt(num); // error
}
if (isBiggerInt(num)) {
    printNum(num); // ok
    printInt(num); // ok
    printBiggerInt(num); // ok
}

소리가 나지 않더라도 유용할 수 있습니다. 그러나 처음에 말했듯이 확장 가능해야 합니까, 아니면 @disjukr이 제안한 대로 구현할 수 있습니까? (후자의 경우 @disjukr 의 확장 불가능한 방식으로 구현하는 것이 좋습니다.)

주제 에서 @DanielRosenwasser 첫 번째 댓글에 답장:
쉼표로 구분된 목록의 경우 ^ 및 $ 앵커를 사용해야 합니다(일부 문자열의 유효성을 검사하려는 대부분의 경우 관련됨). 그리고 앵커는 반복을 피하는 데 도움이 됩니다. 예를 들어 정규 표현식은 /^((dog|cat|fish)(,|$))+$/

문자열 유형이 정규식 /#[0-9]{6}/ 되도록 허용하고 정규식 ${TColor} 유형을 중첩할 수 있습니다.

type TColor = 'red' | 'blue' | /#[0-9]{6}/;
type TBorderValue = /[0-9]+px (solid|dashed) ${TColor}/

결과:

let border1: TBorderValue = '1px solid red'; // OK
let border2: TBorderValue = '1px solid yellow'; // TSError: .....

사용 사례: TypeScript typestyle "유형 안전" CSS 스타일을 작성하기 위한 전용 라이브러리가 있습니다. 라이브러리가 런타임에 사용할 메서드를 노출해야 하기 때문에 위에서 제안한 기능은 크게 도움이 될 것입니다. 제안된 문자열 정규식 유형은 대신 컴파일 시간에 코드를 유형 검사할 수 있고 개발자에게 뛰어난 인텔리센스를 제공할 수 있습니다.

@DanielRosenwasser @alexanderbird @Igmat : IMO 이 제안은 TypeScript 및 웹 개발의 판도를 바꿀 것입니다. 현재 구현을 막고 있는 것은 무엇입니까?

확장성과 유형 방출이 나머지 기능을 방해해서는 안 된다는 데 동의합니다. 이러한 측면에 대한 명확한 경로가 없으면 나중에 있을 때 구현하세요.

문자열이 아닌 UUID 유형을 찾고자 여기에 도착했습니다. 따라서 이 경우 문자열을 정의하는 정규식을 갖는 것이 굉장할 것입니다. + 유형의 유효성을 확인하는 방법(Email.test 예제)도 도움이 될 것입니다.

@skbergam 다시 한번 직접 구현해보려고 합니다. 하지만 TS 프로젝트는 정말 거대하고 저도 작업이 있어서 진행이 거의 없습니다. 누군가 TS 확장에 대한 더 많은 경험이 있다면 도움을 주시면 감사하겠습니다...

두 개의 동일하지 않은 정규 표현식 간에 하위 유형/할당 가능성 관계를 설정할 수 없기 때문에 이것이 명목 유형을 효과적으로 생성한다는 점은 흥미롭습니다.

@RyanCavanaugh 이전에 @maiermic이 댓글을 달았습니다.

편집: 이 문제는 다항식 시간에 해결할 수 있는 것 같습니다(정규 표현식에 대한 포함 문제 참조).

그러나 그것으로 충분하지 않을 수 있습니까? 정규 표현식 관계가 많지 않기를 희망하지만 결코 알 수 없습니다.

유형 검사와 관련하여 정규 표현식 복제가 마음에 들지 않고 typeof a const가 충분하지 않은 경우(예: .d.ts 파일) TS는 valueof e 에 대해 어떻게 생각합니까? e iff e 의 리터럴 값은 리터럴이고, 그렇지 않으면 오류입니다( undefined 와 같은 것을 내보냄)?

@maxlk 또한 주제에서 벗어 /^((dog|cat|fish)(,(?=\b)|$))+$/ with test https://regex101.com/r/AuyP3g/1. 이것은 쉼표 뒤의 단어 문자에 대해 긍정적인 lookahead를 사용하여 DRY 방식으로 사전을 강제로 재검증합니다.

안녕하세요!
이 상태는 어떻습니까?
가까운 시일 내에 이 기능을 추가할 예정입니까? 로드맵에서 이에 대한 내용을 찾을 수 없습니다.

@lgmat lib.d.ts 에서 사용 가능한 정의만 사용하여 구문을 한 줄 화살표 함수로 제한하는 것은 어떻습니까?

그 놀라운 개선 사항을 사용할 수 있습니까? 적어도 알파 릴리스에서는?

정규식 유효성 검사 유형은 테스트 작성에 적합하며 하드 코딩된 입력의 유효성 검사도 좋습니다.

+1. 우리의 사용 사례는 매우 일반적이며 'dd/mm/YYYY'와 같은 문자열 날짜 형식이 필요합니다.

제안된 대로 매우 멋진 기능이 될 수 있지만 잠재력이 부족합니다.

• 출력은 항상 스팅이지만(컴파일 시간을 확인했지만) 구조화된 개체를 가져올 방법이 없습니다.
• 문법은 regexp가 할 수 있는 것으로 제한되고 많은 것을 할 수 없습니다. 정규 표현식의 문제는 정규 표현식이고 결과는 트리가 아니라 목록이며 임의의 긴 중첩 수준을 표현할 수 없다는 것입니다.
• 파서는 제한적이며 확장할 수 없는 타입스크립트 문법으로 표현되어야 합니다.

더 나은 방법은 #21861에서 제안한 것처럼 구문 분석을 아웃소싱하고 플러그인으로 내보내는 것입니다. 이 방법은 위의 모든 것이 더 가파른 학습 곡선의 대가로 문제가 되지 않지만 이봐! regexp 검사는 그 위에 구현되어 원래 제안이 여전히 유지되고 더 고급 기계에서 나올 수 있습니다.

내가 말했듯이 더 일반적인 방법은 리터럴에 대한 사용자 지정 구문 공급자입니다. #21861

예:

const uri: via URIParserAndEmitter = http://google.com; 
console.log(uri); // --> { protocol: 'http', host: 'google.com', path: undefined, query: undefined, hash: undefined }

const a: via PositiveNumberParser = 10; // --> 10
const b: via PositiveNumberParser = -10; // --> error

const date: via DateParser = 1/1/2019; // --> new Date(2019, 1, 1)

@lgmat lib.d.ts 에서 사용 가능한 정의만 사용하여 구문을 한 줄 화살표 함수로 제한하는 것은 어떻습니까?

@zspitz 는 그것이 가능하지만 기본적으로 안전을 위해 금지되어 있는 것처럼 많은 사람들을 불행하게 만들 것입니다.

그 놀라운 개선 사항을 사용할 수 있습니까? 적어도 알파 릴리스에서는?

내가 아는 한 이것은 여전히 ​​제안이 필요합니다. @gtamas , @AndrewEastwood

또한 #11152가 이것에 영향을 미칠 것이라고 생각합니다.

@Igmat 귀하의 제안은 유효성 검사를 문자열 유형에서만 유용하도록 제한합니다. @rylphs 제안에 대해 어떻게 생각하세요? 이렇게 하면 모든 기본 유형에 대해 보다 일반적인 유효성 검사가 가능합니다.

type ColorLevel = (n:number) => n>0 && n<= 255
type RGB = {red:ColorLevel, green:ColorLevel, blue:ColorLevel};
let redColor:RGB = {red:255, green:0, blue:0}   //OK
let wrongColor:RGB = {red:255, green:900, blue:0} //wrong

그러나 나는 이 메커니즘을 기본형을 넘어 기본형이 아닌 유형으로 확장하는 것이 너무 많을 것이라고 생각합니다.

내가 볼 수 있는 주요 문제는 보안 문제입니다. 일부 악성 코드는 유형을 확인하는 동안 버퍼를 사용하여 사용자의 메모리를 가져옵니다. 우리는 이것과 관련하여 많은 샌드박싱을 구현해야 합니다. 차라리 문자열과 숫자에 대한 두 가지 솔루션을 보고 싶습니다.

RegExp는 이를 악의적으로 사용할 수 있는 유일한 방법은 역추적 표현식 을 만드는

한 가지 점은 @DanielRosenwasser 가 다양한 정규식 엔진 구현에 대해 제기한 문제가

그것은 사실입니다. 이것은 좋지 않지만 코드베이스에 필요한 regExp의 "현대적인" 부분을 지정하여 해결할 수 있습니다. 모든 노드 에서 작동하는 일반(ES3입니까?) regexp로 기본 설정됩니다. 그리고 새로운 플래그와 lookbehind 어설션을 활성화하는 옵션이 있습니다.

const unicodeMatcher = /\u{1d306}/u;
let value: typeof unicodeMatcher;
function(input: string) {
  value = input;  // Invalid
  if (input.match(unicodeMatcher)) {
    value = input;  // OK
  }
}

사용자가 고급 플래그로 플래그를 비활성화한 경우.

let value: typeof unicodeMatcher = '𝌆';  // Warning, string literal isn't checked, because `variable` is of type `/\u{1d306}/u`.

알려주지 않으면 TypeScript는 고급 RegExp를 평가하지 않습니다. 그러나 무슨 일이 일어나고 있는지, 고급 RegExp 검사를 활성화하는 방법을 설명하는 경고를 제공해야 한다고 제안합니다.

사용자가 고급 플래그로 플래그를 활성화 하고 그의 노드가 이를 지원하는 경우.

let value: typeof unicodeMatcher = '𝌆';  // OK

사용자가 고급 플래그로 플래그를 활성화 하고 그의 노드가 이를 지원하는 경우.

let value: typeof unicodeMatcher = '𝌆';  
// Error, NodeJS does not support advanced RegExp, upgrade NodeJS to version X.Y.Z, or disable advanced RegExp checking.

합리적인 방법이라고 생각합니다.
프로그래머 팀은 일반적으로 동일한 버전의 NodeJS를 사용하거나 모든 코드베이스가 최신 버전을 사용하는 사람을 위해 작동하기 때문에 쉽게 업그레이드할 수 있습니다.
솔로 프로그래머는 즉석에서 쉽게 적응할 수 있으며,

이 문제의 현재 상태는 무엇입니까? TypeScript가 이렇게 엄청난 잠재력과 수십 가지의 멋진 제안을 가지고 있다는 사실이 참으로 안타깝습니다.

AFAIK의 원래 제안 은 필요하지 않고 실제로 필요하지 않은 Emit 개요 를 제외하고는 좋았으므로 제안을 차단해서는 안 됩니다.

해결하려는 문제는 정규식 리터럴(문자열 및 숫자 리터럴과 효과적으로 동일하므로 어렵지 않아야 함)과 유형 연산자 patternof ( typeof 와 유사)의 도입으로 해결할 수 있습니다 keyof ), 정규식 리터럴 유형을 사용하고 _validated string_ 유형을 반환합니다. 다음과 같이 사용할 수 있습니다.

type letterExpression = /[a-zA-Z]/;
let exp: letterExpression;
exp = /[a-zA-Z]/; // works
exp = /[A-Za-z]/; // error, the expressions do not match

type letter = patternof letterExpression;
type letter = patternof /[a-zA-Z]/; // this is equivalent

let a: letter;
a = 'f'; // works
a = '0'; // error

const email = /some-long-email-regex/;
type email = patternof typeof email;

declare let str: string;
if (str.match(email)) {
  str // typeof str === email
} else {
  str // typeof str === string
}

@m93a 초기 제안을 할 때 추가 유형 연산자로 이러한 솔루션에 대해 생각하지 않았습니다.

유형에 의해 발생하는 방출 영향을 제거하는 이 접근 방식이 더 장황해 보이지만 좋아합니다.

그리고 이것은 새로운 키워드 추가를 건너뛰기 위해 이 제안을 확장하는 방법을 생각하게 합니다.

4단계가 필요합니다.

1. regexp-validated string literal 유형 추가:
   TypeScript type Email = /some-long-email-regex/;
2. core lib의 RegExp 인터페이스를 일반으로 변경해 보겠습니다.
   TypeScript interface RegExp<T extends string = string> { test(stringToTest: string): stringToTest is T; }
3. 실제 코드에서 정규식 리터럴에 대한 유형 유추 변경:
   TypeScript const Email = /some-long-email-regex/; // infers to `RegExp</some-long-email-regex/>`
4. InstanceType 와 같은 conditional types 기능을 사용하여 유형 도우미를 추가합니다.
   TypeScript type ValidatedStringType<T extends RegExp> = T extends RegExp<infer V> ? V : string;

사용 예:

const Email = /some-long-email-regex/;
type Email = ValidatedStringType<typeof Email>;

const email: Email = `[email protected]`; // correct
const email2: Email = `emexample.com`; // compile time error

let userInput: string;
if (Email.test(userInput)) {
    // `userInput` here IS of type `Email`
} else {
    // and here it is just `string`
}

@이그맷 쿨. 귀하의 제안은 TypeScript에 대해 더 자연스럽게 느껴지고 컴파일러에 대한 변경이 덜 필요합니다. 이는 아마도 좋은 일입니다. 내 제안의 유일한 장점은 정규식 리터럴이 문자열 및 숫자 리터럴과 동일하게 느껴질 수 있다는 것입니다. 이는 일부 사람들에게 혼동을 줄 수 있습니다.

let a: 'foo' = 'foo'; // works
let b: 42 = 42; // works
let c: /x/ = /x/; // error

그러나 나는 당신의 제안의 단순함이 단점을 능가한다고 생각합니다.

편집: 나는 ValidatedStringType<R> 의 길이가 정말 마음에 들지 않습니다. 검증된 문자열 패턴 을 호출하기로 결정했다면 결국 PatternOf<R> 사용할 수 있습니다. 귀하의 유형이 입력하는 데 시간이 더 오래 걸린다는 말은 아닙니다. 대부분의 사람들은 처음 세 글자를 입력하고 탭을 누르기만 하면 됩니다. 단지 더 큰 코드 스파게티케이션 영향이 있을 뿐입니다.

@Igmat 당신의 솔루션은 개발 시점에서 훌륭하지만 가독성이 올라갈수록 @m93a가 제안한 가능성이 훨씬 더 나을 것입니다. 내부적으로도 거의 같은 방식으로 표현할 수 있다고 생각하지만 최대한 간단하게 사용자에게 제시해야 합니다.

@Akxe 저는 개발자가 매우 구체적인 사용 사례가 하나만 있는 다른 키워드를 추가하는 것을 좋아할 것이라고 생각하지 않습니다.

@RyanCavanaugh 이에 대한 귀하의 의견을 말씀해 주시겠습니까? (특히 원래 제안서 와 마지막 4개의 의견(이것은 제외).) 감사합니다! :+1:

문자열에 대한 일반 인수를 갖는 것은 어떻습니까? 기본값은 .* 입니까?

let a: 'foo' = 'foo'; // works
let b: 42 = 42; // works
let c: /x/ = /x/; // works
let d: string<x.> = 'xa'; // works

문자열 리터럴 'foo' 는 string<foo> 의 설탕으로 간주될 수 있습니다.

나는 ValidatedStringType<R> 의 길이가 정말 마음에 들지 않습니다. 검증된 문자열 _patterns_를 호출하기로 결정했다면 결국 PatternOf<R> 사용할 수 있습니다.

@m93a , IMO, 이 경우 이미 존재하는 InstanceType 및 ReturnType 도우미와 일치하도록 PatternType<R> 라고 부르는 것이 좋습니다.

@amir-arad, 흥미롭습니다. 이 경우 interface RegExp 어떻게 될까요?

@RyanCavanaugh 도움이된다면 새로 찾은 방법으로 원래 제안을 다시 작성할 수 있습니다. 내가해야합니까?

@amir-arad 제안한 구문이 나머지 TypeScript와 충돌합니다. 이제 형식을 임의의 표현식이 아닌 일반 인수로만 전달할 수 있습니다. 제안한 구문은 매우 혼란스러울 것입니다.

형식을 취하고 형식을 반환하는 함수인 것처럼 제네릭 형식을 생각하십시오. 다음 두 코드 조각은 의미와 구문 모두에서 매우 가깝습니다.

function foo(str: string) {
  return str === 'bar' ? true : false
}

type foo<T extends string> = T extends 'bar' ? true : false;

새 구문은 JavaScript의 정규식이 let all = String(.*) 로 작성되어야 한다고 제안하는 것과 같습니다. 이는 함수 호출 구문을 못쓰게 남용하는 것입니다. 그러므로 나는 당신의 제안이 별로 의미가 없다고 생각합니다.

@ m93a 내 제안은 자바 스크립트가 아닌 유형 주석에 대한 것입니다.

내 머리 꼭대기에서 @Igmat ,

interface RegExp {
    test(stringToTest: string): stringToTest is string<this>;
}

@amir-arad, 죄송합니다. 귀하의 제안에 더 귀중한 세부 정보를 추가할 수는 없지만 string 는 매우 기본적인 기본 요소이기 때문에 언뜻 보기에는 전체 TS 컴파일러에 대한 매우 중요한 변경처럼 보입니다.

명백한 문제가 보이지는 않지만 그러한 제안은 훨씬 더 자세하고 기존의 많은 시나리오와 목적에 대한 적절한 정당성을 포함해야 한다고 생각합니다.
당신의 제안은 하나의 유형을 추가하고 하나의 기본 유형을 변경하는 반면 내 제안은 하나의 유형만 추가합니다.

불행히도 저는 그러한 기능에 대한 제안을 작성하는 데 많은 시간을 할애할 준비가 되지 않았습니다(또한 TS의 모든 제안이 상당한 지연 없이 구현되지는 않았다는 것을 알 수 있습니다). 필요한 경우 내 피드백을 기꺼이 제공하겠습니다.

이러한 regexp 유형이 실제 정규식(정규가 아닌 Perl과 같은 정규식이 아님)인 경우 이를 결정론적 FSM으로 변환하고 여기에 대해 데카르트 곱 구성을 사용하여 모든 결합 및 분리를 얻을 수 있습니다. 정규식은 부울 연산에서 닫힙니다.

또한 문자열 리터럴 유형이 원자적이지 않고 컴파일 타임 문자 목록으로 표시되는 경우 라이브러리의 모든 연산자를 구현할 수 있습니다. 성능이 약간 저하될 뿐입니다.

편집: 실수를 수정합니다.

Mithril이 이것들을 실제로 사용할 수 있다는 점에 주목하기 위해 들르면, 일반적인 경우에 Type-safe가 그것 없이는 거의 불가능합니다. 이것은 하이퍼스크립트와 JSX 구문 모두의 경우입니다. (우리는 둘 다 지원합니다.)

• 우리의 수명 주기 후크 oninit , oncreate , onbeforeupdate , onupdate , onbeforeremove 및 onremove 에는 고유한 후크가 있습니다. 특별한 프로토타입.
• DOM vnode의 이벤트 핸들러는 말 그대로 on 시작하는 다른 모든 것이며, 우리는 이벤트 리스너 함수와 이벤트 리스너 객체( handleEvent 메소드 사용)를 모두 지원하며 addEventListener removeEventListener .
• 적절한 경우 키와 참조를 지원합니다.
• 다른 모든 것은 지원 DOM 노드 자체의 존재 여부에 따라 속성 또는 속성으로 처리됩니다.

따라서 정규식으로 검증된 문자열 유형 + 유형 부정을 사용 하여 DOM vnode에 대해 다음을 수행할 수 있습니다.

interface BaseAttributes {
    // Lifecycle attributes
    oninit(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    oncreate(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    onbeforeupdate(
        vnode: Vnode<this, Vnode<Attributes, []>>,
        old: Vnode<this, Vnode<Attributes, []>>
    ): void;
    onupdate(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    onbeforeremove(vnode: Vnode<this, Vnode<Attributes, []>>): void | Promise<void>;
    onremove(vnode: Vnode<this, Vnode<Attributes, []>>): void;

    // Control attributes
    key: PropertyKey;
}

interface DOMAttributes extends BaseAttributes {
    // Event handlers
    [key: /^on/ & not keyof BaseAttributes]: (
        ((this: Element, ev: Event) => void | boolean) |
        {handleEvent(ev: Event): void}
    );

    // Other attributes
    [key: keyof HTMLElement & not keyof BaseAttributes & not /^on/]: any;
    [key: string & not keyof BaseAttributes & not /^on/]: string;
}

interface ComponentAttributes extends BaseAttributes {
    // Nothing else interesting unless components define them.
}

(이러한 정규식에서 그룹을 추출할 수 있는 것도 좋지만 숨을 쉬지 않을 것입니다.)

편집: 제안서에서 몇 가지 중요한 세부 사항을 명확히 하십시오.
편집 2: 실제로 수학적으로 정확하도록 테크니컬 비트를 수정합니다.
편집 3: 단일 문자 공용체의 일반 주연 지원 추가

다음은 이 문제를 훨씬 더 쉽게 해결하기 위한 구체적인 제안입니다. 템플릿 리터럴 유형입니다.

또한 전체 정규 표현식은 다른 유형과 합치기 쉽기 때문에 아마도 좋은 생각이 아니라고 생각합니다. 템플릿 리터럴 유형이 더 나을 수도 있습니다.

• `value` - 이것은 말 그대로 "value" 와 동일합니다.
• `value${"a" | "b"}` - 이것은 문자 그대로 "valuea" | "valueb" 와 동일합니다.
• `value${string}` - 이것은 regexp /^value/ 와 기능적으로 동일하지만 "value" , "valuea" 및 "valueakjsfbf aflksfief fskdf d" 모두 할당 가능합니다.
• `foo${string}bar` - 이것은 regexp /^foo.*bar$/ 와 기능적으로 동일하지만 정규화하기가 조금 더 쉽습니다.
• 물론 여러 보간이 있을 수 있습니다. `foo${string}bar${string}baz` 은 유효한 템플릿 리터럴 유형입니다.
• 보간 은 string 확장 해야 하며 재귀적이어서는 안 됩니다. (두 번째 조건은 기술적인 이유입니다.)
• 템플릿은 입력 문자 A 입력하는 문자 템플릿에 할당 할 B 문자열의 집합에 할당 할 경우 만 A 스트링의 세트의 서브 세트에 할당 할 B .

위에 추가하여 T 는 단일 문자 문자열 리터럴 유형으로만 구성되어야 하는 특수 starof T 유형이 존재합니다. string 는 starof (...) 의 유형 별칭으로 존재합니다. 여기서 ... 는 lone을 포함하여 U+0000에서 U+FFFF까지의 모든 단일 UCS-2 문자열 리터럴의 합집합입니다. 대리인. 이를 통해 ES base-10 숫자 리터럴에 대한 전체 문법을 정의할 수 있습니다. 예를 들면 다음과 같습니다.

type DecimalDigit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9";
type Decimal = `${DecimalDigit}{starof DecimalDigit}`

type Numeric = `${(
    | Decimal
    | `${Decimal}.${starof DecimalDigit}`
    | `.${Decimal}`
)}${"" | (
    | `E${Decimal}` | `E+${Decimal}` | `E-${Decimal}`
    | `e${Decimal}` | `e+${Decimal}` | `e-${Decimal}`
)}`

마찬가지로 특정 내장 메서드는 다음과 같은 유형을 반환하도록 조정할 수 있습니다.

• Number.prototype.toString(base?) - 이것은 정적으로 알려진 base 대해 위의 Numeric 유형 또는 일부 변형을 반환할 수 있습니다.
• +x , x | 0 , parseInt(x) 및 유사 - x 가 위에 정의된 대로 Numeric 것으로 알려진 경우 결과 유형은 다음을 수행할 수 있습니다. 리터럴 숫자 유형으로 적절하게 추론됩니다.

마지막으로 Key extends `on${infer EventName}` ? EventTypeMap[TagName][EventName] : never 와 같이 일치하는 그룹을 추출할 수 있습니다. 템플릿 추출은 항상 전체 이름으로 작동한다고 가정하므로 임의 포함을 검색하려면 ${string} 보간을 명시적으로 사용해야 합니다. 이것은 욕심이 없기 때문에 ` "foo.bar.baz" extends ${infer T}.${infer U} ? [T, U] : never 는 ["foo", "bar.baz"] 이 아니라 ["foo.bar", "baz"] ["foo", "bar.baz"] 반환합니다.

기술적인 관점에서 이것은 원시 정규 표현식보다 구현하기에 훨씬 더 적합합니다. JS 정규 표현식은 규칙적이지 않습니다. 역참조를 사용하여 상황에 따라 달라지며 다음 형식으로 많은 복잡성을 수반합니다. 이러한 방식으로 재귀를 차단하는 한 템플릿 리터럴 유형은 각각 하나의 정규 언어를 생성합니다. 기본 이론과 매우 밀접하게 일치합니다(그러나 그것의 하위 집합만 지원함).

• 빈 언어: ""
• 조합: "a" | "b"
• 연결: `${a}${b}`
• Kleene 별(일부): starof T ( T 에는 단일 문자 및 공용체만 포함될 수 있습니다.)

이 문자열의 부분 집합 확인 하위 유형 만들 수 있습니다 서브 그래프의 동형 문제가 최악의 시나리오를, 그러나 약간 큰 구속 요인은 여기에 있습니다 :

1. 지금까지 일반적인 경우는 나무로 모델링할 수 있는 작은 유한 문자열의 합집합입니다. 이것은 작업하기에 비교적 분명합니다. (위의 일치 알고리즘이 복잡해지기 때문에 로프로 결합하는 것을 권장하지 않지만 단일 문자 결합 및 유사한 단일 분할 + 결합으로 정규화하는 것은 완벽하게 괜찮습니다.)

2. 전체 통합 유형을 방향 그래프로 모델링할 수 있습니다. 여기서:

   1. 이러한 문자의 별표 결합은 상위 노드가 각 문자 및 하위 그래프의 각 하위 노드 모두에 대해 가장자리를 갖고 각 문자가 다른 모든 문자 및 하위 그래프의 모든 하위 노드 모두에 대해 가장자리를 갖는 하위 그래프입니다.
   2. 그래프의 나머지 부분은 다른 모든 가능성을 나타내는 방향성 트리와 같은 구조를 유지합니다.

   이 Math.SE 채팅에 따르면 (약 여기 에서 시작) 이 결과 그래프에는 경계가 있는 속(즉, 다른 가장자리에 대한 유한한 수의 점프*)이 있고 starof 없는 것으로 나타났습니다. 유형 평등 이 이를 강력히 의심합니다. (위에 링크된 Wikipedia 기사에는 "알고리즘"에 몇 가지 예가 있으며 특수 대소문자가 적용될 수 있는 섹션을 참조합니다.)




3. 이러한 키 중 어느 것도 여기에 실제 런타임 비용 때문에 대부분은 다른 것들에 의해 실제로 상각하고, 큰 될 가능성이 없습니다. 작은 키의 경우 빠르면 충분합니다.




4. 비교될 모든 하위 그래프는 루트 노드인 적어도 하나의 노드를 공유합니다. (이것은 문자열의 시작을 나타냅니다.) 따라서 이것은 그 자체로 문제 공간을 극적으로 줄이고 다항식 시간 검사를 보장합니다.

그리고 물론 이러한 유형 간의 교차는 사소하지 않지만 위의 제한 사항으로 인해 유사한 상환 요소가 존재한다고 생각합니다. 특히, 마지막 제한은 분명히 다항식 시간으로 만듭니다.

* 수학적으로 속은 우리 프로그래머들에게 다소 직관적이지 않게 정의되지만(점프 없이 그래프를 그리기 위해 표면에 찔러야 하는 최소 구멍 수), 제한된 속(구멍 수 제한)은 제한된 수의 점프를 의미합니다. .

이 구체적인 제안을 사용하여 이 주석의 예를 번역하는 방법은

// This would work as a *full* type implementation mod implementations of `HTMLTypeMap` +
// `HTMLEventMap`
type BaseAttributes = {
    // Lifecycle attributes
    oninit(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    oncreate(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    onbeforeupdate(
        vnode: Vnode<this, Vnode<Attributes, []>>,
        old: Vnode<this, Vnode<Attributes, []>>
    ): void;
    onupdate(vnode: Vnode<this, Vnode<Attributes, []>>): void;
    onbeforeremove(vnode: Vnode<this, Vnode<Attributes, []>>): void | Promise<void>;
    onremove(vnode: Vnode<this, Vnode<Attributes, []>>): void;

    // Control attributes
    key: PropertyKey;
}

interface HTMLTypeMap {
    // ...
}

interface HTMLEventMap {
    // ...
}

// Just asserting a simple constraint
type _Assert<T extends true> = never;
type _Test0 = _Assert<
    keyof HTMLTypeMap[keyof HTMLTypeMap] extends `on${string}` ? false : true
>;

type EventHandler<Event> =
    ((this: Element, ev: Event) => void | boolean) |
    {handleEvent(ev: Event): void};

type Optional<T> = {[P in keyof T]?: T[P] | null | undefined | void}

type DOMAttributes<T extends keyof HTMLAttributeMap> = Optional<(
    & BaseAttributes
    & {[K in `on${keyof HTMLEventMap[T]}` & not keyof BaseAttributes]: EventHandler<(
        K extends `on${infer E}` ? HTMLEventMap[E] : never
    )>}
    & Record<
        keyof `on${string & not keyof HTMLEventMap}` & not keyof BaseAttributes,
        EventHandler<Event>
    >
    & Pick<HTMLTypeMap[T], (
        & keyof HTMLTypeMap[T]
        & not `on${string}`
        & not keyof BaseAttributes
    )>
    & Record<(
        & string
        & not keyof HTMLTypeMap[T]
        & not keyof BaseAttributes
        & not `on${string}`
    ), string | boolean>
)>;

편집: 이렇게 하면 Lodash의 _.get 메서드 및 _.property(path) 메서드 및 _.map(coll, path) 약식과 같은 속성 약어를 사용하여 관련 메서드의 90%를 올바르게 입력할 수도 있습니다. 아마 제가 생각하지 못한 다른 몇 가지가 있을 것입니다. 하지만 아마도 그것이 제가 생각할 수 있는 가장 큰 것입니다. (해당 유형의 구현은 독자에게 연습 문제로 남겨두겠지만 {0: ..., 1: ...}[Path extends "" ? 0 : 1] 와 같이 즉시 인덱싱된 레코드가 있는 조건부 유형의 일반적인 트릭과 그 조합을 사용하면 가능하다고 확신할 수 있습니다.

제 추천은 정규식 유형을 구현하는 데 사용할 수 있는 유형 공급자 구현에 노력을 집중하는 것입니다.

정규식 유형을 직접 구현하는 대신 유형 공급자를 사용하는 이유는 무엇입니까? 때문에

1. TypeScript에 많은 새로운 가능성을 추가하는 보다 일반적인 솔루션으로 정규식 문자열 유형의 값을 보는 사람들을 넘어 더 많은 개발자 그룹의 지원을 더 쉽게 얻을 수 있습니다.
2. typescript repo 소유자는 이 아이디어에 열려 있는 것으로 보이며 올바른 제안을 기다리고 있습니다. #3136 참조

F#에는 오픈 소스 정규식 유형 공급자가 있습니다.

유형 공급자에 대한 일부 정보: https://link.medium.com/0wS7vgaDQV

유형 공급자가 구현되고 정규식 유형 공급자가 오픈 소스 라이브러리로 구현되면 다음과 같이 사용할 것이라고 상상할 수 있습니다.

type PhoneNumber = RegexProvider</^\d{3}-\d{3}-\d{4}$/>
const acceptableNumber: PhoneNumber = "123-456-7890"; //  no compiler error
const unacceptableNumber: PhoneNumber = "hello world"; // compiler error

@AlexLeung 적어도이 요청에 대해서는 올바른 방법이 아니라고 확신합니다.

• TypeScript는 명목적으로 타이핑된 것이 아니라 구조적으로 타이핑되었으며 문자열 리터럴 조작을 위해 그 구조적 정신을 유지하고 싶습니다. 이와 같은 유형 공급자는 RegexProvider</^foo$/> 가 "foo" 와 동등하게 취급 되지 않고 그것의 명목 하위 유형인 명목 string 하위 유형을 생성합니다. 게다가 RegexProvider</^foo$/> 와 RegexProvider</^fo{2}$/> 는 별개의 두 가지 유형으로 취급되는데, 저는 그런 것을 좋아하지 않습니다. 대신 내 제안은 핵심에 있는 문자열과 직접 통합되며, 형식 언어 인식 이론의 직접적인 영향을 받아 자연스럽게 맞도록 합니다.
• 광산을 사용하면 문자열을 연결할 수 있을 뿐만 아니라 Key extends `on${infer K}` ? K : never 또는 Key extends `${Prefix}${infer Rest}` ? Rest : never 를 통해 문자열의 일부를 추출할 수 있습니다. 유형 공급자는 이 기능을 제공하지 않으며 이러한 기능이 추가 되어야 하는 경우 어떻게
• 내 것은 개념적 수준에서 훨씬 더 간단합니다. 문자열 연결 유형을 추가하고 조건부 유형의 RHS에 대해 역을 추출하는 기능을 추가하는 것이 좋습니다. 또한 정규 표현식 /.*/ 대신 string 자체와 통합할 것을 제안합니다. API 변경이 필요하지 않으며, 나머지 코드 기반과 대부분 분리되는 이론적으로 복잡한 두 부분을 제외하고 템플릿 리터럴 유형을 다른 유형에 할당할 수 있는지 여부를 계산하고 문자열에서 슬라이스를 추출하는 것은 더 간단하지 않더라도 비슷합니다. , 구현.

BTW, 내 제안은 여전히 PhoneNumber 예제를 입력할 수 있습니다. 좀 더 장황하지만 다른 곳에 존재하는 데이터가 아니라 이미 TS 영역에 있는 데이터를 모델링하려고 합니다(F#의 형식 공급자가 가장 유용한 용도). (기술적으로 여기에서 가능한 전화번호의 전체 목록으로 확장된다는 점은 주목할 가치가 있습니다.)

type D = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9";
type PhoneNumber = `${D}${D}${D}-${D}${D}${D}-${D}${D}${D}${D}`;

RegexProvider^foo$/> 및 RegexProvider^fo{2}$/>는 두 가지 고유한 유형으로 처리됩니다.

형식 공급자는 일부 equals 또는 compare 메서드의 구현을 요구할 수 있으므로 정규식 형식 공급자의 형식 공급자 작성자는 위의 두 경우가 동일한 형식임을 정의할 수 있습니다. 유형 공급자 작성자는 원하는 대로 구조적 또는 명목적 유형을 구현할 수 있습니다.

아마도 문자열 리터럴 유형을 유형 공급자로 구현하는 것도 가능할 것입니다. 구문이 동일할 수 있다고 생각하지 않지만 다양한 수의 인수를 사용하는 유형 공급자와 가까워질 수 있습니다.

type D = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9";
type PhoneNumber = StringTemplateMatcherProvider<D, D, D, "-", D, D, D, "-", D, D, D, D>;

@AlexLeung 하지만 "123-456-7890" 유형을 유형에 할당할 수 있습니까? (그렇다면 구현이 복잡해지고 검사기가 많이 느려집니다.)

당면한 논의와 관련이 있는데, 유형이 고정된 길이가 아닌 경우(예: 전화번호) 어떻게 되나요? 최근에 이것을 사용하고 싶었던 한 가지 상황은 thread_{number} 형식의 방 이름을 저장하는 것입니다.

이러한 값과 일치하는 정규식은 thread_[1-9]\d* 입니다. 제안된 내용으로는 그러한 형식을 일치시키는 것이 실현 가능하지 않거나 심지어 가능하지도 않습니다. 값의 숫자 부분은 이 상황에서 0보다 큰 _any_ 길이가 될 수 있습니다.

@jhpratt 나는 그것을 수용하기 위해 starof ("0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9") ↔ /^\d*$/ 형태로 제안을 수정했습니다. 왜냐하면 약간만 변경하면 되었기 때문입니다. string 가 /^[\u0000-\uFFFF]*$/ 로 최적화하는 것과 같은 방식으로 최적화하므로 일반화하기로 결정했습니다.

계산 복잡성 문제로 인해 임의의 비재귀적 합집합을 허용하는 것과 같이 starof 그 이상으로 확장하고 싶지 않습니다. 두 개의 임의 정규식*이 동일한지 확인하는 것은 다항식 공간 또는 다항식 시간 ( 둘 다 최소 DFA로 변환하고 비교하십시오 - 일반적인 방법이지만 실제로는 매우 느림). 그러나 두 가지 방법 모두 실제로는 a{2} ). 기본적으로 불가능합니다(지수 복잡성) . 이것은 동등성을 위한 것이며, 할당 가능성을 확인하는 데 필요한 정규 표현식이 다른 정규 표현식과 일치하는 문자열의 하위 집합과 일치하는지 확인하는 것은 분명히 훨씬 더 복잡할 것입니다.

* 수학적인 의미의 정규식: () , (ab) , (a|b) 및 (a*) , 여기서 a 는 단일 문자만 포함합니다 (a|b) a 및 b 는 (잠재적으로 다른) 이 목록의 각 구성원입니다.

이것은 아마도 어리석은 질문일 것입니다. 하지만... 적절하게 제한되어 있다면 유효성 검사 기능(람다 또는 명명)을 지원하는 것이 왜 상당히 쉽지 않습니까?

예를 들어 다음 요소가 유효성 검사기임을 나타내기 위해 ":"를 사용한다고 가정합니다(이에 대한 의견이 있는 경우 ":"을 원하는 대로 대체).

type email = string : (s) => { return !!s.match(...) }
type phone_number = string : (n) => { return !!String(n).match(...) }
type excel_worksheet_name = string : (s) => { return (s != "History") && s.length <= 31 && ... }

초기 시작으로 typescript는 다음과 같은 유효성 검사 기능만 수락할 수 있습니다.

• "기본" 유형이어야 하는 필수/가정된 단일 인수가 있습니다.
• 유효성 검사기 함수에 정의된 참조 변수만
• 값을 반환합니다(검증 프로세스에서 bool로 강제 변환됨).

위의 조건은 typescript 컴파일러가 확인하기 쉬운 것처럼 보이며 일단 이러한 조건이 가정되면 구현 복잡성의 많은 부분이 사라질 것입니다.

또한 초기 범위를 관리 가능한 크기로 제한해야 하는 경우:

• 유효성 검사 기능은 기본 유형(문자열, 숫자)의 하위 집합에만 추가할 수 있습니다.

이 마지막 제한이 꼭 필요한 것은 아니라고 생각하지만, 그것이 필요한지 여부에 대한 질문이 있는 경우에도 위의 제한이 있는 솔루션이 있기 때문에 그것에 대해 많은 시간을 할애할 가치가 있다고 생각하지 않습니다. 여전히 광범위한 실제 사용 사례를 해결할 수 있습니다. 또한 위의 제한 사항을 나중에 완화하면 기본 구문을 변경할 필요가 없고 단순히 컴파일러가 지원하는 언어의 폭을 확장하는 간단하고 자연스러운 확장이 될 것이기 때문에 위의 제한 사항의 단점이 거의 없다고 생각합니다.

@mewalig 그것은 런타임 함수처럼 보이는 것이 실제로 런타임에 실행 되지 않고 컴파일 시간에(그리고 할당 가능성을 확인하려는 때마다) 실행된다는 것을 의미합니다. 이 함수 는 런타임 (변수, 함수)

게다가 당신은 일반적으로 컴파일러가 당신이 던지는 어떤 것, 특히 잘못 최적화된 함수나 완전히 악의적인 while(true){} 를 실행하는 것을 원하지 않습니다. 메타프로그래밍을 하고 싶다면 현명하게 설계해야 합니다. 런타임 코드가 컴파일 시간에 실행되도록 무작위로 허용하는 것이 "PHP 방식"이 될 것입니다.

마지막으로 제안한 구문은 일반적인 패턴을 전환합니다.

let runtime: types = runtime;

(즉, 결장 뒤의 유형) 뒤집어서, 효과적으로

type types = types: runtime;

끔찍합니다. 제안해 주셔서 감사합니다. 하지만 그것은 확실히 나쁜 생각입니다.

이 함수 는 런타임 (변수, 함수)

컴파일러가있는 경우 물론 그들은, ECMA 스크립트는 사용할 수 런타임 수 ( tsc BTW, 않습니다!). fetch() 와 같은 컴파일 시간 의미와 런타임 의미의 모호성 문제가 분명히 있지만 이것이 바로 반복에 관한 것입니다.

런타임 코드가 컴파일 시간에 실행되도록 무작위로 허용하는 것이 "PHP 방식"이 될 것입니다.

C++ constexpr functions 와 매우 유사합니다. 해결책은 constexpr 는 constexpr 만 사용할 수 있지만 모든 것이 constexpr 사용할 수 있다고 말하는 것입니다. 그런 다음 상당히 강력할 수 있는 컴파일 타임 파일 시스템에 대해 constexpr -동등한 버전의 파일 시스템을 가질 수 있습니다.

구문도 대략 괜찮아 보입니다. LHS는 유형이고 물론 RHS도 일종의 유형입니다. 내 문제는 "기본" 유형을 넘어 유형을 구성하는 방법에 관한 것이지만 그것도 모두 해결할 수 있습니다.

제안해 주셔서 감사합니다. 하지만 그것은 확실히 나쁜 생각입니다.

그것은 결국 나쁜 생각이 될 수 있지만 지금은 타이프스크립트의 목표에서 너무 멀리 벗어나야 할 가능성이 있는 매우 덜 구체화된 아이디어를 보고 있습니다. 그것과 유사한 좋은 아이디어가 없을 수도 있다는 의미는 아닙니다!

이 기능에 대한 논의는 지금은 중단된 것 같습니다( PR 은 종료되었으며 디자인 노트 팀에 따르면 _명목 유형과 일반화된 인덱스 서명이 있을 때까지 여기에 커밋하고 싶지 않습니다. 그리고 그것들이 어떻게 생겼는지 알아야 합니다._).

어쨌든, 정규식 패턴 추출을 지원하는 현재 PR에 대한 또 다른 가상 확장을 제안하고 싶습니다( @isiahmeadows 가 자신의 제안을 제시했지만 솔직히 지금은 머리를 감쌀 수 없습니다...).

나는 현재 PR을 정말 좋아하고 그것을 기반으로 내 제안을 할 것입니다. 함수(및 infer 키워드가 있는 조건부 유형)에 대해 가지고 있는 제네릭 유형 인수 추론을 기반으로 구문을 제안하고 싶습니다. 사람들은 이미 일반 함수에서 전달된 리터럴 개체에서 유형을 "추출"할 수 있다는 직관을 가지고 있기 때문입니다.

예를 들어 이 유형이 있습니다.

type Prop1 = /(\w)\.(\w)/

이 유형을 사용하여 리터럴 유형을 테스트할 수 있습니다.

const goodLiteral = "foo.bar";
const badLiteral = "foo";
const regextTest: Prop1 = goodLiteral; //no error
const regextTest: Prop1 = badLiteral; //compiler error

function funProp1(prop: Prop1) { } 

funProp1(goodLiteral); //no error
funProp1(badLiteral); //error

그러나 함수 매개변수에서 Regex 유형을 사용할 때 꺾쇠 괄호 구문을 사용하여 일치하는 문자열을 추론하려는 것을 의미할 수 있습니다. 예를 들어

type Prop1 = /(\w)\.(\w)/
const Prop1 = /(\w)\.(\w)/

const goodLiteral = "foo.bar";
const badLiteral = "foo";

function funProp1<M1 extends string, M2 extends string>(prop: Prop1<M1, M2>) : [M1, M2] 
{
    const m = prop.match(Prop1);
    return [m[1], m[2]];
} 

const res1 = funProp1(goodLiteral); //no error. Function signature inferred to be funProp<"foo", "bar">(prop: Prop1<"foo", "bar">) : ["foo", "bar"]
const res2 = funProp1(badLiteral); //compiler error

res1 의 유추된 유형은 ["foo", "bar"]

유용한가요?

1. Ember.js/lodash 가져오기 기능

다음 코드가 작동하도록 유형 안전 "문자열 경로" getter를 구현할 수 있습니다.

const deep = get(objNested, "nested.very.deep")

그러나 가능한 get 의 "깊이"의 고정된 최대 수에 대해 많은 과부하를 피하려면 이 문제를 해결해야 할 것입니다.

1. 매핑된 유형에서 추출된 매개변수를 사용합니다.

예를 들어 https://github.com/Microsoft/TypeScript/issues/12754 와 같은 작업을 수행할 수 있다면 { [ StripAsyncSuffix<P> for P in K ] : T[P] } 와 같은 구문, 누군가 이미 이와 유사한 것을 제안 함)

아마 다른 사용 사례도 있을 것입니다. 하지만 대부분은 이 두 가지 유형에 적합할 것 같습니다(1. 제공된 문자열 리터럴을 기반으로 적절한 유형 파악, 2. 입력 유형의 속성 이름을 새로 정의된 유형의 새 속성 이름으로 변환)

이것은 우리가 할 수 있는 일입니다.

저는 현재 URL의 유효성을 검사할 수 있도록 맞춤 린트 규칙을 만들고 있습니다. 하지만 선택적 매개변수를 정의할 수 있다면 훨씬 더 쉬울 것입니다.

일반적으로 이것은 코드 기반 전체에서 props의 유효성을 주장할 수 있는 훨씬 더 많은 권한을 제공합니다.

유형 공급자, 템플릿 문자열 리터럴 또는 기타 제안에 대한 이동이 있습니까? 이것은 훌륭한 도구가 될 것입니다.

이에 대한 나의 해결 방법은 현재와 같은 마커 인터페이스를 사용하는 것입니다 이 .

interface TickerSymbol extends String {}

유일한 문제는 인덱스 키로 사용하려는 경우 string 로 캐스팅해야 한다는 것입니다.

interface TickerSymbol extends String {}
var symbol: TickerSymbol = 'MSFT';
// declare var tickers: {[symbol: TickerSymbol]: any}; // Error: index key must be string or number
declare var tickers: {[symbol: string]: any};
// tickers[symbol]; // Type 'TickerSymbol' cannot be used as an index type
tickers[symbol as string]; // OK

그러나 JavaScript는 String (대문자 S 포함)의 인덱스 유형에서 괜찮은 것 같습니다.

var obj = { one: 1 }
var key = new String('one');
obj[key]; // TypeScript Error: Type 'String' cannot be used as an index type.
// but JS gives expected output:
// 1

@DanielRosenwasser 여기 에 제안 이 있고

위의 제안을 검토했으며 몇 가지 질문과 의견이 있습니다.

지금까지 제안서의 문제점

방출을 생성하는 유형

우리는 유형 시스템을 완전히 지우기 위해 최선을 다하고 있으므로 방출된 코드를 생성하기 위해 유형 별칭이 필요한 제안은 범위를 벗어납니다. 이 스레드에서 명확하지 않은 방식으로 발생한 몇 가지 예를 강조하겠습니다.

https://github.com/microsoft/TypeScript/issues/6579#issuecomment -220180091 - 함수와 유형을 동시에 생성

type Integer(n:number) => String(n).macth(/^[0-9]+$/)

https://github.com/microsoft/TypeScript/issues/6579#issuecomment -261519733 - 이 작업도 수행합니다.

type CssColor = /^#([0-9a-f]{3}|[0-9a-f]{6})$/i;
// ... later
setFontColorFromString(color: string) {
    fontColor = color;// compile time error
    if (CssColor.test(color)) {
    //  ^^^^^^^^ no value declaration of 'CssColor' !
        fontColor = color;// correct
    }
}

다시 말씀드리지만 이것은 초보자용 입니다. TypeScript의 유형은 구성 가능 하며 유형에서 JS를 내보내는 것은 이 세계에서 불가능합니다. 현재까지 가장 긴 제안 에는 광범위한 방출 유형이 있습니다. 이것은 작동하지 않습니다. 예를 들어, 다음과 같이 광범위한 유형 지정 방출이 필요합니다.

type Matcher<T extends number | boolean> = T extends number ? /\d+/ : /true|false/;
function fn<T extends number | boolean(arg: T, s: Matcher<T>) {
  type R = Matcher<T>
  if (R.test(arg)) {
      // ...
  }
}
fn(10, "10");
fn(false, "false");

교차로 금지

실제로 일반적인 유형과 정규식으로 검증된 유형은 실제로 다르기 때문에 합집합과 교차를 올바르게 처리하는 방법에 대한 규칙이 필요합니다.

type Regex_1 = / ... /;
type Regex_2 = / ... /;
type NonRegex = { ... };
type test_4 = Regex_1 & NonRegex;// compile time error

TypeScript는 교차의 인스턴스화에서 오류를 발생시킬 수 없으므로 이것은 최종 디자인의 일부가 아닙니다.

인간 공학

전반적으로 가장 두드러진 시사점은 동일한 RegExp를 두 번 (값 공간에서 한 번, 유형 공간에서 한

유형 방출에 대한 위의 우려를 감안할 때 가장 현실적인 솔루션은 값 공간에 표현식을 작성하는 것입니다.

// Probably put this in lib.d.ts
type PatternOf<T extends RegExp> = T extends { test(s: unknown): s is infer P } ? P : never;

const ZipCode = /^\d\d\d\d\d$/;
function map(z: PatternOf<typeof ZipCode>) {
}

map('98052'); // OK
map('Redmond'); // Error

물론 여전히 RegExp를 형식 공간에 작성할 수 있지만 런타임 유효성 검사를 사용할 수 없으며 문자가 아닌 사용에는 다시 테스트 또는 어설션이 필요합니다.

function map(z: /^\d\d\d\d\d$/) { }
map('98052'); // OK
map('Redmond'); // Error

function fn(s: string) {
    map(s); // Error
    // typo
    if (/^\d\d\d\d$/.test(s)) {
        // Error, /^\d\d\d\d$/ is not assignable to /^\d\d\d\d\d$/
        map(s);
    }

    if (/^\d\d\d\d\d$/.test(s)) {
        // OK
        map(s);
    }
}

사용 사례 수집 및 설명

새로운 유형의 경우 다음과 같은 몇 가지 예를 이상적으로 보고 싶습니다.

• 해결되고 있는 문제에는 더 나은 대안 이 없습니다(아직 언어에 없는 그럴듯한 대안 포함).
• 실제 코드베이스에서 의미 있는 빈도 로 문제가 발생합니다.
• 제안된 솔루션은 해당 문제를 잘 해결합니다.

리터럴의 컴파일 타임 유효성 검사

이 스레드는 다양한 사용 사례를 의미합니다. 구체적인 예는 더 드물었다. 문제는 이러한 예 중 많은 부분이 완전 하지 않다는 것입니다. 유효한 입력을 거부하는 RegExp를 사용합니다.

• 글꼴 색상 - 16진수 색상을 허용하는 AFAIK는 "흰색" 또는 "하늘색"도 허용합니다. 이것은 또한 rgb(255, 0, 0) 구문을 잘못 거부합니다.
• 주민등록번호, 우편번호 등 - 좋습니다. 하지만 코드에 문자 그대로의 주민등록번호 또는 우편번호가 있는 이유는 무엇입니까? 이것이 실제로 명목 유형이 필요합니까? RegExp로 정확하게 설명할 수 없는 문자열의 하위 클래스가 있으면 어떻게 됩니까? "경쟁 제안" 참조
  
  
  
  • 정수 - "3e5" 잘못 거부합니다.
  
  
  • 이메일 - 이것은 일반적으로 나쁜 생각으로 간주됩니다 . 다시 말하지만 코드에 이메일 주소 문자열 리터럴
  
  
  • CSS 테두리 사양 - 독립 실행형 라이브러리가 자체 지원하는 DSL을 설명하는 정확한 RegEx를 제공할 수 있다고 믿을 수 있습니다.
  
  
  • 테스트 작성 - 테스트 코드가 잘못된 입력을 많이 제공해야 하기 때문에 이것이 거의 대위법이지만 하드코딩된 입력이 의미가 있는 곳입니다.
  
  
  • 날짜 형식 - 어떻게/왜? Date 에는 이를 위한 생성자가 있습니다. 입력이 런타임 외부에서 오는 경우 명목 유형을 원합니다.
  
  
  • URI - 당신이 상상할 수있는 fetch 지정합니다 host 로되지 않는에 http(s?):
  
  

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

한 가지 우려 사항은 "정밀도염"입니다. 누군가가 확실히 Typed에 유용하게 표시되고 라이브러리의 모든 함수에 RegExp 유형을 추가하여 모든 비문자적 호출이 중단되면 어떻게 됩니까? 설상가상으로 정의 파일 작성자는 유효성 검사 RegExp의 "올바른 철자"가 무엇인지 소비자와 정확히 동의해야 합니다.
이것은 모든 라이브러리가 URL로 자격이 있는 것, 호스트 이름으로 자격이 있는 것, 이메일로 자격이 있는 것 등에 대한 자체 버전이 있고 두 개의 라이브러리를 연결하는 사람이 있는 바벨탑 상황으로 빠르게 우리를 안내하는 것 같습니다. 컴파일러를 만족시키기 위해 형식 주장을 삽입하거나 정규 표현식을 복사해야 합니다.

런타임 검사 시행

이전 인체 공학 섹션의 fn 와 같이 함수의 인수가 이전 정규식에 의해 검증되었는지 확인하려는 검사에 대한 논의가 있었습니다. 테스트가 필요한 RegEx가 잘 알려진 경우 이는 간단하고 가치가 있습니다. 그러나 그것은 큰 "만약"입니다. 제 기억으로는 유효성 검사 정규식을 제공하는 단일 라이브러리가 기억나지 않습니다. 유효성 검사 기능을 제공할 수 있지만 이는 제공할

이 평가에 대한 반대 증거는 환영합니다.

속성 키 / 정규식 문자열 인덱서

일부 라이브러리는 속성 이름에 따라 개체를 처리합니다. 예를 들어 React에서 이름이 aria- 시작하는 모든 소품에 유형을 적용하려고 합니다.

interface IntrinsicElements {
    // ....
    [attributeName: /aria-\w+/]: number | string | boolean;
}

이것은 사실상 직교 개념입니다(Regex 속성 키를 추가하지 않고 Regex 유형을 추가할 수 있으며 그 반대의 경우도 마찬가지입니다).

TODO(나 또는 누구나): 이에 대한 별도의 문제를 엽니다.

경쟁 제안

명목 또는 태그 유형

어떤 종류의 명목/태그 유형이 있다고 가정해 보겠습니다.

type ZipCode = make_unique_type string;

그런 다음 함수를 작성할 수 있습니다.

function asZipCode(s: string): ZipCode | undefined {
    return /^\d\d\d\d\d$/.test(s) ? (s as ZipCode) : undefined;
}

이 시점에서 정말 RegExp 유형이 필요할까요? 자세한 내용은 "컴파일 시간" 확인 섹션을 참조하세요.

반대로, 이제 우리가 명목상의 유형을 정규식 유형을 가지고하지 가정 해 봅시다. 검증되지 않은 시나리오에 사용하기 시작(ab)하는 것은 꽤 유혹적입니다 .

type Password = /(IsPassword)?.*/;
type UnescapedString = /(Unescaped)?.*/;
declare function hash(p: Password): string;

const p: Password = "My security is g00d"; // OK
const e: UnescapedString = "<div>''</div>"; // OK
hash(p); // OK
hash(e); // Error
hash("correct horse battery staple"); // OK

스레드에서 일반적인 것은 이러한 정규식이 테스트 코드의 유효성을 검사하는 데 도움이 된다는 것입니다. 프로덕션 시나리오에서 코드가 하드코딩된 리터럴이 아닌 런타임 제공 문자열에 대해 실행되더라도 테스트 문자열이 " 옳은". 이것은 대신에 명목/태그/브랜드 문자열에 대한 인수로 보일 수 있습니다. 왜냐하면 유효성 검사 기능을 어느 쪽이든 작성하고 테스트의 이점은 철저하게 실행된다는 것을 알 수 있다는 것입니다(따라서 테스트 입력의 모든 오류는 개발 주기 초기에 플래그 지정).

비이슈

우리는 다음과 같은 측면에 대해 논의했으며 차단 요소가 아닌 것으로 간주합니다.

호스트 기능

최신 런타임은 이전 런타임보다 더 많은 RegExp 구문을 지원합니다. TypeScript 컴파일러가 실행되는 위치에 따라 최신 RegExp 기능을 구문 분석하는 런타임 기능에 따라 특정 코드가 유효하거나 유효하지 않을 수 있습니다. 실제로, 대부분의 새로운 RegExp 기능은 상당히 난해하거나 그룹 일치와 관련되어 여기에서 대부분의 사용 사례와 일치하지 않는 것 같습니다.

성능

RegExes는 무한한 양의 작업을 수행할 수 있으며 큰 문자열에 대한 일치는 임의로 많은 양의 작업을 수행할 수 있습니다. 사용자는 이미 다른 수단을 통해 스스로 DOS를 수행할 수 있으며 악의적으로 비효율적인 RegExp를 작성할 가능성은 거의 없습니다.

하위 유형( /\d*/ -> /.*/ ?), 조합, 교차로 및 거주 불가능

이론상 /\d+/ 는 /.+/ 의 알 수 있는 하위 유형입니다. 한 RegExp가 다른 RegExp의 순수한 하위 집합과 일치하는지(특정 제약 조건에서) 결정하는 알고리즘이 존재하지만 분명히 표현식을 구문 분석해야 합니다. 실제로 우리는 RegExpes가 일치하는 항목에 따라 암시적 하위 유형 관계를 형성하지 않는 것에 대해 100% 괜찮습니다. 이것은 아마도 더 바람직합니다.

할당 가능성 관계가 올바르게 정의되어 있는 한 Union 및 Intersection 작업은 "즉시" 작동합니다.

TypeScript에서 두 개의 기본 유형이 교차점에서 "충돌"하면 never 줄어듭니다. 두 개의 RegExp가 교차할 때 두 표현식의 교차와 일치하는 새 RegExp를 생성하는 대신 /a/ & /b/ 로 유지합니다. never 로의 감소는 없을 것입니다. 우리는 어떤 문자열도 양쪽을 만족시킬 수 없다는 것을 증명하는 알고리즘이 필요합니다(이것은 앞에서 설명한 re: subtyping과 유사한 문제입니다).

다음 단계

요약하면 다음 단계는 다음과 같습니다.

• 정규식 이름 속성 키(일명 정규식 문자열 인덱서)에 대한 별도 문제 제출
• 문자열 리터럴의 컴파일 타임 유효성 검사를 위한 구체적이고 그럴듯한 사용 사례 얻기
  
  
  
  • 예: 이로부터 큰 이점을 얻을 수 있는 확실히 유형 또는 기타 라이브러리의 함수 식별
  
  
• 명목/태그/브랜드 유형이 문자가 아닌 유효성 검사에 대해 보다 유연하고 광범위하게 적용 가능한 솔루션인지 이해
• 이미 유효성 검사 RegEx를 제공하는 라이브러리 식별

사용 사례: 하이퍼스크립트(https://github.com/hyperhype/hyperscript)와 같은 기능
하이퍼스크립트 함수는 일반적으로 h('div#some-id') 와 같이 호출됩니다.
regex-ish 패턴 매처는 h 의 반환 유형을 결정할 수 있도록 하며 이는 예제의 경우 HTMLDivElement가 됩니다.

유형 시스템이 문자열 리터럴을 추가할 수 있다면 기본적으로 모든 CSS 속성이 유형 안전할 수 있습니다.

declare let width: number;
declare let element: HTMLElement;

element.style.height = `${width}px`;
// ...or
element.style.height = `${width}%`;

CSS 선택기의 유효성도 검사할 수 있습니다( element.class#id - 유효, div#.name - 유효하지 않음)

캡처 그룹이 (어쨌든) 작동한다면 Lodash의 get 메소드는 유형 안전할 수 있습니다.

var object = { 'a': [{ 'b': { 'c': 3 } }] };

_.get(object, 'a[0].b.c');

이것도 문제가 될 수 있습니다.

interface IOnEvents {
  [key: PatternOf</on[a-z]+/>]: (event: Event) => void;
}

interface IObservablesEndsOn$ {
  [key: PatternOf</\$$/>]: Observable<any>;
}

사용 사례: 하이퍼스크립트(하이퍼하이프/하이퍼스크립트) 유사 함수

해당 정규식은 어떻게 생겼습니까? 또는 어떤 유효성 검사를 제공합니까? 정규식 기반 함수 오버로딩을 위한 것입니까?

FWIW 라이브러리는 네임스페이스 태그 이름을 허용하고 임의의 태그 이름에서도 작동합니다.

> require("hyperscript")("qjz").outerHTML
'<qjz></qjz>'

또한 클래스 및 id 값의 무제한 혼합을 허용합니다.

> require("hyperscript")("baz.foo#bar.qua").outerHTML
'<baz class="foo qua" id="bar"></baz>'

CSS 선택기의 유효성도 검사할 수 있습니다.

CSS 선택기 는 정규식으로 유효성을 검사할 수 없습니다.

해당 정규식은 어떻게 생겼습니까? 또는 어떤 유효성 검사를 제공합니까? 정규식 기반 함수 오버로딩을 위한 것입니까?

OP는 아니지만 HTMLDocument#createElement() 오버로드와 같은 것으로 가정합니다. 예:

// ...
export declare function h(query: /^canvas([\.#]\w+)*$/): HTMLCanvasElement;
// ...
export declare function h(query: /^div([\.#]\w+)*$/): HTMLDivElement;
// ...

RE가 불완전하다고 확신합니다. 이것은 규칙적인 방식으로 많은 컨텍스트에서 사용되는 CSS 선택기를 검증하는 특별한 경우입니다. 예를 들어, 복잡한 선택기를 사용하는 경우 HTMLDocument.querySelector() 가 HTMLElement 를 폴백으로 반환하는 것은 완벽합니다.

그러나 실행 가능하고 유용한 비 오버로딩 예제가 있는지 궁금합니다.

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

내 사용 사례는 TickerSymbol 를 나타내는 문자열이 있는 CCXT 라이브러리의 이 주석 에서 설명한 것입니다. 정규식 패턴을 확인하는지 여부는 별로 신경 쓰지 않지만 string 의 하위 유형으로 처리되기를 원하므로 더 엄격한 할당, 매개변수 유형 검사 등을 얻습니다. 함수형 프로그래밍을 할 때 매우 유용합니다. 이를 통해 런타임에는 그냥 일반 문자열인 TickerSymbols, Currencies, Assets 등을 컴파일 타임에 쉽게 추적할 수 있습니다.

@omidkrad 이것은 정규식 검증 유형이 아닌 명목 유형 이 필요한 것처럼 들립니다.

@m93a 제 경우에는 명목 유형으로 문제가 없지만 동일한 사용 사례의 경우 더 엄격한 유형 검사 및 문자열 유형 자체 문서화를 위해 정규식 검증 유형을 사용할 수 있습니다.

CSS 선택기의 유효성도 검사할 수 있습니다.

CSS 선택기 는 정규식으로 유효성을 검사할 수 없습니다.

글쎄요, 정규 표현식이 그것들을 하나로 묶을 수 있게 해준다면 우리는 CSS 정규 표현식을 복사할 수 있을 것입니다..., 그렇죠?

(초안) CSS 유형 객체 모델

https://drafts.css-houdini.org/css-typed-om/

https://developers.google.com/web/updates/2018/03/cssom

문자열 형식의 CSS 모델을 사용하려는 욕구를 잠재적으로 완화합니다.

el.attributeStyleMap.set('padding', CSS.px(42));
const padding = el.attributeStyleMap.get('padding');
console.log(padding.value, padding.unit); // 42, 'px'

@RyanCavanaugh 특히 Mithril의 경우 태그 이름은 ^([^#\.\[\]]+) 의 캡처 그룹을 통해 추출되지만(기본값은 "div" ), 일치하는 ^(${htmlTagNames.join("|")}) 이면 충분합니다. 그래서 내 제안을 사용 하면 이것이 내 목적에 충분할 것입니다.

type SelectorAttrs = "" | `#${string}` | `.${string}`;

type GetTagName<T extends string> =
    T extends SelectorAttrs ? "div" :
    T extends `${keyof HTMLElementTagNameMap & (infer Tag)}${SelectorAttrs}` ? T :
    string;

이벤트 및 속성에 관해서는 일단 부정 유형이 도착하면 다음과 같이 전환할 수 있습니다.

type EventsForElement<T extends Element> =
    T extends {addEventListener(name: infer N, ...args: any[]): any} ? N : never;

type MithrilEvent<E extends string> =
    (E extends EventsForElement<T> ? HTMLElementEventMap[E] : Event) &
    {redraw?: boolean};

type Attributes<T extends Element> =
    LifecycleAttrs<T> &
    {[K in `on${string}` & not LifecycleAttrs<T>](
        ev: K extends `on${infer E}` ? MithrilEvent<E> : never
    ): void | boolean} &
    {[K in keyof T & not `on${string}`]: T[K]} &
    {[K in string & not keyof T & not `on${string}`]: string};

BTW, 이 원활한 통합과 복잡성 회피가 내가 여전히 리터럴 정규 표현식보다 내 제안을 선호하는 이유입니다.

하지만 순수한 정규 표현식 유형으로 이 작업을 수행할 방법이 없습니다. 나는 그것을 지적하고 싶다.

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

Bent 는 예상되는 응답 유형을 설명하는 문자열로 제공된 것에 따라 다른 반환 유형을 갖습니다.

bent('json')('https://google.com') // => Promise<JSON>
bent('buffer')('https://google.com') // => Promise<Buffer | ArrayBuffer>
bent('string')('https://google.com') // => Promise<String>

또한 method 및 url과 같은 다른 인수를 문자열로 허용하지만 이러한 인수는 모든 위치에 나타날 수 있으므로 모든 반환 유형( 'json' | 'buffer' | 'string' )을 설명하기 위해 공용체를 사용하려고 하면 대신 멍청해질 것입니다. 유니온의 url 및 메서드 유형과 결합할 때 string 됩니다. 즉, 첫 번째 호출에서 제공된 유형을 기반으로 반환 유형을 자동으로 유추할 수 없습니다.

@Ovyerus 정규식 유형이 어떻게 도움이 될까요? 무엇을 쓸 것으로 예상하십니까? 오버로드 또는 조건부 유형을 사용하여 벤트의 동작과 유사한 것을 모델링할 수 있습니다.

type BentResponse<Encoding> = Promise<
    Encoding extends "json" ? MyJsonType :
    Encoding extends "buffer" ? Buffer | ArrayBuffer :
    Encoding extends "string" ? string :
    Response
>;

declare function bent<T extends string>(urlOrEncoding: T): (url: string) => BentResponse<T>;

http://www.typescriptlang.org/play/index.html#code/C4TwDgpgBAQhB2wBKEDOYD29UQDwFF4BjDAEwEt4BzAPigF4oAFAJwwFtydcBYAKCiCohEhWpQIAD2AJSqKACIAVqiwKoAfigBZEAClV8ACrhoALn5DhxMpSoTps + QoBGAVwBmHiC3VaYnt4sUAA UACCLCwAhiABXj5QFgJCIrbiUjLwcoqowCx2flB5BeLJVijoWDj8NADc + - + PykEEQANtEs0B5uxMDkWFAuCMC4Rg5ZOSV2NAAUbiytAPIsaWJUZlBGAJQbcwsbU9RbDHRwiJWY2HhG9Y18lDIsHtFE0PFBUADeUAD67gksDbReAgKAAX34Dx8z1eOn0hhMkC vxUWCBIPBdxm0VQIGIUBmx3odE liErQgwCgkg2ugMWER0EY0QA7tFyFShogZspDAotjyABbAYBgVBmAD0Eqk0XYYApADoSOx + + + Q0 GCBVsgA

아, 죄송합니다. 내 문제는 기본 URL을 감지하기 위해 문자열 시작 부분에 일치하는 http(s): 라인에 더 가깝습니다.

Bent의 서명은 다음과 같습니다.

type HttpMethods = 'GET' | 'PATCH' | ...
type StatusCode = number;
type BaseUrl = string; // This is where I would ideally need to see if a string matches http(s):
type Headers = { [x: string]: any; };

type Options = HttpMethods | StatusCode | BaseUrl | Headers;

function bent(...args: Options[]): RequestFunction<RawResponse>
function bent(...args: (Options | 'json')[]): RequestFunction<JSON>
// and so on

그러나 BaseUrl 를 문자열로 사용하면 HttpMethods 및 반환 유형 공용체가 흡수되어 string 로 끝납니다. 문자열로 "부적절하게" 사용하면 기본 URL로 사용할 항목을 결정하기 위해 ^http: 또는 ^https: 가 있는지 확인하므로 구부러진 작동 방식과 일치합니다.

정규식 유형이 있는 경우 BaseUrl을 type BaseUrl = /^https?:/ 로 정의할 수 있으며, 이렇게 하면 HTTP 메서드 또는 응답 인코딩이 아닌 문자열을 이상적으로 확인하고 string 로 흡수하지 않습니다. 유형.

정확히는 저도 똑같습니다.

--
프로콥 시멕

2019년 10월 20일 03:23:30, Michael Mitchell([email protected])
썼다:

오, 나는 내 문제가
일치하는 http(s): 문자열의 시작 부분에서 기본 URL을 감지합니다.

Bent의 서명은 다음과 같습니다.

유형 HttpMethods = '가져오기' | '패치' | ...유형 StatusCode = 숫자;유형 BaseUrl = 문자열; // 여기에서 문자열이 http(s):type Headers = { [x: string]: any;와 일치하는지 이상적으로 확인해야 합니다. };
유형 옵션 = HttpMethods | 상태 코드 | 기본 URL | 헤더;
함수 벤트(...args: 옵션[]): RequestFunction함수 벤트(...args: (옵션 | 'json')[]): RequestFunction// 등등

그러나 BaseUrl을 문자열로 사용하면 HttpMethods를 흡수하고 반환합니다.
유형 유니온은 문자열로 끝납니다. 그것을 문자열로 갖는 것
또한 "부적절하게" 구부러진 작동 방식과 일치합니다. 존재 여부를 확인하기 때문입니다.
^http: 또는 ^https: 중 무엇을 기반으로 사용해야 하는지 결정하기 위해
URL.

정규식 유형이 있는 경우 BaseUrl을 BaseUrl = /^https?:/ 유형으로 정의할 수 있습니다.
이상적으로는 HTTP 메서드가 아닌 문자열을 올바르게 확인하거나
응답 인코딩뿐만 아니라 문자열 유형으로 흡수하지 않습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/microsoft/TypeScript/issues/6579?email_source=notifications&email_token=ABJ3U4JNK3V5MV4DJH73ZU3QPOXJFA5CNFSM4BZLAVSKYY1ABBYT0ZY01000003PNVWWK3TUL52HS4DFVREXG43VMVBW63
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABJ3U4PHBXO4766LK7P7UXDQPOXJFANCNFSM4BZLAVSA
.

유스 케이스에 대한 생각은 함수에 대한 매개변수 유형을 감지하는 것이었습니다.

기본적으로 식별자를 나타내는 문자열의 잘 정의된 정규식 형식이 있습니다. 데코레이터를 사용할 수 있지만 확장된 문자열 유형을 사용하면 함수에 전달된 식별자를 나타내는 유형을 사용할 수 있습니다.

반복해서 말씀드리자면, 유형이 지정된 방식으로 작성하려는 JavaScript 코드의 예가 필요합니다. 그렇지 않으면 모델링하려는 대상(및 모델링 방법이 이미 있는지 여부)만 추측할 수 있습니다.

@DanielRosenwasser 아래는 타이핑을 강제하려는 코드의 예입니다. http://www.typescriptlang.org/play/index.html#code/C4TwDgpgBAqjCSARKBeKBnYAnAlgOwHMBYAKFIGMAbAQ3XVnQiygG9SoOoxcA3a4aJn45yULBGoATAPZ5KIKAFtq + GIywAuWAmRoA5NQCcEAAwBGQwCMArAFoAZtYBMAdlsAWcvYActw2ZM7JzNJF28TCCcANgtLPXZOAHpErl5 + QWBhUXEpWXklFTw1Ji04JFQoMycAZihkqAA5AHkAFSgAQQAZTqaAdQBRRASOeu4cPgEMTOARMQkZOQVlVXVSnQq9PGlgW2pbAFd9nEk9OpSAZQAJJphO5Ga2gCF + ju6 + 와우 ++ BBL-oAlYZQciyTBYfbkYDSLAACkBnC4 + 0slFmxzWSAANHDOGBEcjRJYsNQ8JItKD8ARMSR4fCcUjZuocNRKFo8PtFJYmJTqdjcbNyDkBJJHiA0boGEwAHTLIrqACUrFICQAvqQVSQgA

@yannickglt RegExp 유형이 아닌 명목 유형을 원하는 것 같습니까? 다음과 같은 임의의 사이트 유효성 검사 호출을 호출자가 표시할 것으로 예상하지 않습니다.

// OK
someFunc('a9e019b5-f527-4cf8-9105-21d780e2619b');
// Also OK, but probably really bad
someFunc('a9e019b5-f527-4cf8-9106-21d780e2619b');
// Error
someFunc('bfe91246-8371-b3fa-3m83-82032713adef');

정규 표현식으로 UUID를 설명 할 수 있다는 사실은 문자열 자체의 형식의 인공물인 반면, 표현하려는 것은 UUID가 지원 형식 이 문자열 인 특수한 종류의 유형이라는

따라서 3.7의 Assertion Functions 와 nominal 기능의 조합 은 이것을 할 수 있습니다(?)

nominal UUID = string

function someFunc(uuid: any): asserts uuid is UUID {
  if (!UUID_REGEX.test(uuid)) {
    throw new AssertionError("Not UUID!")
  }
}

class User {
  private static readonly mainUser: UUID = someFunc('a9e019b5-f527-4cf8-9105-21d780e2619b')
  // private static readonly mainUser: UUID = someFunc(123) // assertion fails
  // private static readonly mainUser: UUID = someFunc('not-a-uuid') // assertion fails
  constructor(
    public id: UUID,
    public brand: string,
    public serial: number,
    public createdBy: UUID = User.mainUser) {

  }
}

이것도 실패할까요?

new User('invalid-uuid', 'brand', 1) // should fail
new User('invalid-uuid' as UUID, 'brand', 1) // 🤔 

잠시 고민하다가 제가 제안한 솔루션에 문제가 생겼어요 🤔
asserts 는 런타임 에만 오류를 발생시킵니다 -> 👎
Regex-Validation 는 컴파일 타임 오류를 유발할 수 있습니다 -> 👍
그렇지 않으면 이 제안은 의미가 없습니다

편집하다:
또 다른 문제: someFunc(uuid: any): asserts uuid is UUID 는 UUID를 반환하지 않고 is UUID -> true 던지거나 반환합니다.
따라서 이 함수를 사용하여 이러한 방식으로 UUID를 mainUser 에 할당할 수 없습니다.

@RyanCavanaugh 우리는 Mithril에 다음을 올바르게 입력하기를 원합니다.

// <div id="hello"></div>
m("div#hello", {
    oncreate(vnode) { const dom: HTMLDivElement = vnode.dom },
})

// <section class="container"></section>
m("section.container", {
    oncreate(vnode) { const dom: HTMLElement = vnode.dom },
})

// <input type="text" placeholder="Name">
m("input[type=text][placeholder=Name]", {
    oncreate(vnode) { const dom: HTMLInputElement = vnode.dom },
})

// <a id="exit" class="external" href="https://example.com">Leave</a>
m("a#exit.external[href='https://example.com']", {
    oncreate(vnode) { const dom: HTMLAnchorElement = vnode.dom },
}, "Leave")

// <div class="box box-bordered"></div>
m(".box.box-bordered", {
    oncreate(vnode) { const dom: HTMLDivElement = vnode.dom },
})

// <details></details> with `.open = true`
m("details[open]", {
    oncreate(vnode) { const dom: HTMLDetailsElement = vnode.dom },
})

// alias for `m.fragment(attrs, ...children)`
m("[", {
    oncreate(vnode) { const dom: HTMLElement | SVGElement = vnode.dom },
}, ...children)

우리는 다음을 정적으로 거부하고 싶습니다.

// selector must be non-empty
m("")

// incomplete class
m("div.")

// incomplete ID
m("div#")

// incomplete attribute
m("div[attr=")

// not special and doesn't start /[a-z]/i
m("@foo")

이상적으로는 정적으로 거부하고 싶지만 우선 순위가 높지 않으며 없이도 생존할 수 있습니다.

// event handers must be functions
m("div[onclick='return false']")

// `select.selectedIndex` is a number
m("select[selectedIndex='not a number']")

// `input.form` is read-only
m("input[type=text][form='anything']")

// `input.spellcheck` is a boolean, this evaluates to a string
// (This is a common mistake, actually.)
m("input[type=text][spellcheck=false]")

// invalid tag name for non-custom element
m("sv")

이것은 훨씬 더 복잡한 유형 정의가 필요하며 사용자가 유형 검사에 실패한 이유를 파악하는 데 도움이 되는 사용자 정의 유형 검사 실패 메시지가 필요합니다.

react-hyperscript와 같은 다른 하이퍼스크립트 라이브러리와 하이퍼스크립트 기반 프레임워크도 비슷한 문제를 가지고 있습니다.

도움이 되었기를 바랍니다!

@isiahmeadows 는 올바른 입력과 함께 브랜드 문자열을 반환하는 일종의 선택기 문자열 빌더를 사용하는 더 좋은 방법입니다. 좋다:

m(mt.div({ attr1: 'val1' }))

@anion155 거기에 m("div", {...attrs}, ...children) 과 함께 사용할 것입니다. 하이퍼스크립트 설탕은 없지만(입력하기 쉽고 처리하기가 훨씬 더 간단함) 그것에 대해 많은 것을 하기에는 너무 늦었습니다.

할 말이 많습니다 . 그러나 나는 참을성이 없습니다. 그래서 제 생각을 조금씩 풀어가겠습니다.

https://github.com/microsoft/TypeScript/issues/6579#issuecomment -542405537

"정밀염"(남자, 나는 그 단어를 좋아합니다)에 대해,
나는 우리가 그것에 대해 너무 걱정할 필요가 없다고 생각합니다.

유형 시스템은 이미 튜링이 완료되었습니다.
이것은 기본적으로 우리가 많은 것에 대해 매우 정확할 수 있음을 의미합니다.
(예를 들어, 모든 SQL을 모델링? 뻔뻔한 플러그 = P)

그러나 (너무 많은) 사람들이 총력을 기울이고 모든 유형 연산자를 미친 방식으로 사용하여 라이브러리가 서로 호환되는 것을 차단하는 것을 보지 못합니다. 나는 도서관 작가들이 충분히 냉정한 경향이 있다고 생각하는 것을 좋아합니다... 맞죠?

문자열 패턴 유형/정규식 유효성이 검증된 문자열 유형을 원하는 경우는 흔하지 않지만 확실히 내 코드 기반의 유형 안전성을 높이는 데 도움이 되었을 것입니다.

사용 사례

머리 꼭대기에서 최근 한 가지 예를 생각할 수 있습니다. (더 많겠지만 나는 건망증인)

스트라이프의 API (지불 처리 플랫폼)과 통합 할 때, 사용 ch_ 에 대해 charge , - 관련 식별자 re_ 에 대해 refund - 관련 식별자 등

PatternOf</^ch_.+/> 및 PatternOf</^re_.+/> 로 인코딩하는 것이 좋았을 것입니다.

이런 식으로 오타를 만들 때,

charge.insertOne({ stripeChargeId : someObj.refundId });

나는 오류를 얻을 것이다,

Cannot assign `PatternOf</^re_.+/>` to `PatternOf</^ch_.+/>`

내가 명목형/태그형 유형을 좋아하는 만큼 인체공학적이지 않고 오류가 발생하기 쉽습니다.
나는 항상 명목형/태그형 유형을 최후의 수단 으로 봅니다. TS 유형 시스템이 모델링할 수 없는 무언가가 있다는 것을 의미하기 때문입니다.

또한 태그가 있는 유형은 팬텀 유형에 적합합니다.
명목형은 기본적으로 결코 유용하지 않습니다.
(좋아요, 제가 편향된 것일 수도 있습니다. 그것들은 unique symbol 때문에 유용합니다. 하지만 저는 제가 완전히 틀리지 않다고 생각하고 싶습니다.)

유효성 검사를 위한 "ValueObject" 패턴은 훨씬 더 나쁩니다. 나는 그것에 대해 이야기하지 않겠습니다.

비교

아래에서 다음을 비교할 것입니다.

• 문자열 패턴 유형/정규식 검증 문자열 유형
• 호칭 유형
• 구조 태그 유형

"ValueObject" 패턴이 최악의 솔루션이라는 데 모두 동의할 수 있으며 비교 시 신경 쓰지 않아도 됩니다. 그렇죠?

문자열 패턴 유형

const stripeChargeIdRegex = /^ch_.+/;
const stripeRefundIdRegex = /^re_.+/;

type StripeChargeId = PatternOf<typeof stripeChargeIdRegex>;
type StripeRefundId = PatternOf<typeof stripeRefundIdRegex>;

declare function takesStripeChargeId (stripeChargeId : StripeChargeId) : void;

declare const str : string;
takesStripeChargeId(str); //Error
if (stripeChargeIdRegex.test(str)) {
  takesStripeChargeId(str); //OK
}
if (stripeRefundIdRegex.test(str)) {
  takesStripeChargeId(str); //Error
}

declare const stripeChargeId : StripeChargeId;
declare const stripeRefundId : StripeRefundId;
takesStripeChargeId(stripeChargeId); //OK
takesStripeChargeId(stripeRefundId); //Error

takesStripeChargeId("ch_hello"); //OK
takesStripeChargeId("re_hello"); //Error

저것 봐.

• 문자열 리터럴에 적합합니다.
• string 리터럴이 아닌 경우에도 나쁘지 않습니다.

명목형...

const stripeChargeIdRegex = /^ch_.+/;
const stripeRefundIdRegex = /^re_.+/;

type StripeChargeId = make_unique_type string;
type StripeRefundId = make_unique_type string;

function isStripeChargeId (str : string) : str is StripeChargeId {
  return stripeChargeIdRegex.test(str);
}
function isStripeRefundId (str : string) : str is StripeRefundId {
  return stripeRefundIdRegex.test(str);
}

declare function takesStripeChargeId (stripeChargeId : StripeChargeId) : void;

declare const str : string;
takesStripeChargeId(str); //Error
if (isStripeChargeId(str)) {
  takesStripeChargeId(str); //OK
}
if (isStripeRefundId(str)) {
  takesStripeChargeId(str); //Error
}

declare const stripeChargeId : StripeChargeId;
declare const stripeRefundId : StripeRefundId;
takesStripeChargeId(stripeChargeId); //OK
takesStripeChargeId(stripeRefundId); //Error

takesStripeChargeId("ch_hello"); //Error? Ughhhh
takesStripeChargeId("re_hello"); //Error

takesStripeChargeId("ch_hello" as StripeChargeId); //OK, BUT UNSAFE
takesStripeChargeId("re_hello" as StripeChargeId); //OK, BUT WAIT! I MESSED UP

const iKnowThisIsValid = "ch_hello";
if (isStripeChargeId(iKnowThisIsValid)) {
  takesStripeChargeId(iKnowThisIsValid); //OK
} else {
  throw new Error(`Wat? This should be valid`);
}

function assertsStripeChargeId (str : string) : asserts str is StripeChargeId {
  if (!isStripeChargeId(str)) {
    throw new Error(`Expected StripeChargeId`);
  }
}
assertsStripeChargeId(iKnowThisIsValid);
takesStripeChargeId(iKnowThisIsValid); //OK

function makeStripeChargeIdOrError (str : string) : StripeChargeId {
  assertsStripeChargeId(str);
  return str;
}
takesStripeChargeId(makeStripeChargeIdOrError("ch_hello")); //OK
takesStripeChargeId(makeStripeChargeIdOrError("re_hello")); //OK, compiles, throws during run-time... Not good

저것 봐.

• 문자열 리터럴의 경우 TERRIBLE .
• 문자열 리터럴 장애를 극복하고 나면 나쁘지 않습니다 ... 맞습니까?

그러나 이 제안의 주요 사용 사례는 문자열 리터럴입니다.
따라서 이것은 끔찍한 대안입니다.

구조 태그 유형...

구조 태그 유형은 명목 유형과 크게 다르지 않습니다...

const stripeChargeIdRegex = /^ch_.+/;
const stripeRefundIdRegex = /^re_.+/;

type StripeChargeId = string & tag { stripeChargeId : void };
type StripeRefundId = string & tag { stripeRefundId : void };

function isStripeChargeId (str : string) : str is StripeChargeId {
  return stripeChargeIdRegex.test(str);
}
function isStripeRefundId (str : string) : str is StripeRefundId {
  return stripeRefundIdRegex.test(str);
}

declare function takesStripeChargeId (stripeChargeId : StripeChargeId) : void;

declare const str : string;
takesStripeChargeId(str); //Error
if (isStripeChargeId(str)) {
  takesStripeChargeId(str); //OK
}
if (isStripeRefundId(str)) {
  takesStripeChargeId(str); //Error
}

declare const stripeChargeId : StripeChargeId;
declare const stripeRefundId : StripeRefundId;
takesStripeChargeId(stripeChargeId); //OK
takesStripeChargeId(stripeRefundId); //Error

takesStripeChargeId("ch_hello"); //Error? Ughhhh
takesStripeChargeId("re_hello"); //Error

takesStripeChargeId("ch_hello" as StripeChargeId); //OK, BUT UNSAFE
takesStripeChargeId("re_hello" as StripeChargeId); //OK, BUT WAIT! I MESSED UP

const iKnowThisIsValid = "ch_hello";
if (isStripeChargeId(iKnowThisIsValid)) {
  takesStripeChargeId(iKnowThisIsValid); //OK
} else {
  throw new Error(`Wat? This should be valid`);
}

function assertsStripeChargeId (str : string) : asserts str is StripeChargeId {
  if (!isStripeChargeId(str)) {
    throw new Error(`Expected StripeChargeId`);
  }
}
assertsStripeChargeId(iKnowThisIsValid);
takesStripeChargeId(iKnowThisIsValid); //OK

function makeStripeChargeIdOrError (str : string) : StripeChargeId {
  assertsStripeChargeId(str);
  return str;
}
takesStripeChargeId(makeStripeChargeIdOrError("ch_hello")); //OK
takesStripeChargeId(makeStripeChargeIdOrError("re_hello")); //OK, compiles, throws during run-time... Not good

저것 봐.

• 문자열 리터럴의 경우 TERRIBLE .
• 문자열 리터럴 장애를 극복하고 나면 나쁘지 않습니다 ... 맞습니까?

그러나 이 제안의 주요 사용 사례는 문자열 리터럴입니다.
따라서 이것은 끔찍한 대안입니다.

또한 이 구조적 태그 유형 예제는 명목 유형 예제의 리터럴(ha, pun) 복사-붙여넣기 입니다.

유일한 차이점은 StripeChargeId 및 StripeRefundId 이 선언되는 방식입니다.

코드는 기본적으로 동일하지만 구조적 유형이 명목 유형보다 낫습니다. (다음 포스트에서 이 점을 명확히 하겠다, 맹세한다).

결론

이 댓글의 결론입니다! 내 전반적인 생각에 대한 결론이 아닙니다!

문자열 패턴 유형/정규식 검증 문자열 유형 은 명목/구조 태그 유형 너무 인위적 이지 않다는 것을 충분히 보여주었습니다.

결론(추가)

가능한 한 기본 유형의 하위 집합을 가져오는 방법이 항상 명목/구조 태그/값-객체 유형보다 선호되어야 합니다.

기본 유형의 하위 집합을 취하는 예,

• string 리터럴
• number 리터럴( NaN, Infinity, -Infinity 제외)
• boolean 리터럴
• bigint 리터럴
• unique symbol 도 symbol 의 하위 집합을 사용하고 있습니다.

위의 예 중 boolean 만 "유한"합니다. 두 가지 값만 있습니다.
개발자는 true 및 false 리터럴을 사용하는 것에 만족합니다. 왜냐하면 더 이상 요구할 것이 없기 때문입니다.

number 유형은 유한하지만 값이 너무 많기 때문에 무한하다고 생각할 수도 있습니다.
우리가 지정할 수 있는 리터럴에도 구멍이 있습니다.

이것이 범위 번호 유형 및 NaN, Infinity, -Infinity 문제가 인기가 있고 계속 나타나는 이유입니다. 무한 집합에서 작은 유한 값 집합을 지정할 수 있다는 것만으로는 충분하지 않습니다.

범위를 지정하는 것은 무한 집합의 큰 유한/무한 부분 집합을 지정해야 할 때 누군가에게 오는 가장 일반적이고 자연스러운 아이디어 중 하나입니다.

bigint 유형은 기본적으로 무한하며 메모리에 의해서만 제한됩니다.

또한 범위 번호 유형 문제의 인기에 기여합니다.

string 유형은 기본적으로 무한하며 메모리에 의해서만 제한됩니다.

이것이 바로 이 문자열 패턴 유형/정규식 검증 문자열 유형 문제가 인기 있는 이유입니다.

정규식을 지정하는 것은 무한 집합의 큰 유한/무한 하위 집합을 지정해야 할 때 누군가에게 오는 가장 일반적이고 자연스러운 아이디어 중 하나입니다.

symbol 타입... 역시 무한대입니다. 또한 거의 무제한입니다.

그러나 symbol 유형의 요소는 거의 모든 면에서 서로 거의 관련이 없습니다. 따라서 아무도 " symbol 의 큰 유한/무한 부분 집합을 지정할 수 있습니까?"라고 묻는 문제를 제기하지 않았습니다.

대부분의 사람들에게 그 질문은 이해가 되지 않습니다. 의미있는 방법은 없습니다(맞나요?)

그러나 기본 요소의 하위 집합을 선언할 수 있는 것만으로는 그다지 유용하지 않습니다. 우리도 필요합니다,

• 추가 작업 없이 올바른 유형의 리터럴을 할당할 수 있어야 합니다.

고맙게도 TS는 이를 허용할 만큼 제정신이 아닙니다.

false 를 (arg : false) => void 로 전달할 수 없다고 상상해보세요!

• 좁히는 방법 내장

  현재 이러한 리터럴의 경우 기본 제공 축소 방식으로 == & === 가 있습니다.

  각 리터럴에 대해 새로운 유형 가드를 작성해야 한다고 상상해보세요!

명목/구조 태그/값-객체 유형의 문제는 기본적으로 위의 두 가지 기준을 충족하지 못한다는 것입니다. 그들은 원시 유형을 객체 유형이 아니지만 어쨌든 객체 유형처럼 처리해야 하는 투박한 유형으로 바꿉니다.

인간 공학

자, 여기에 문자열 패턴 대 명목 태그 유형 및 구조 태그 유형에 대한 자세한 설명이 있습니다.

이러한 인수는 https://github.com/microsoft/TypeScript/issues/15480 에도 적용됩니다.

라이브러리 간 호환성

명목형은 라이브러리 간 호환성 이 최악 입니다.
두 라이브러리에서 unique symbol 를 사용하고 상호 운용하도록 하는 것과 같습니다.
그것은 단순히 할 수 없습니다.
상용구 유형 가드 또는 trust-me-operator( as )를 사용해야 합니다.

어설션 가드에도 더 많은 상용구가 필요합니다.

유형에 라이브러리 간 호환성이 필요하지 않으면 명목 유형을 사용하는 것이 좋습니다...
매우 인체공학적이지 않은 경우에도(위의 예 참조).

구조 유형의 경우 A 라이브러리에 있는 경우

//Lowercase 'S'
type StripeChargeId = string & tag { stripeChargeId : void };

B 라이브러리에는

//Uppercase 'S'
type StripeChargeId = string & tag { StripeChargeId : void };

//Or
type StripeChargeId = string & tag { isStripeChargeId : true };

//Or
type StripeChargeId = string & tag { stripe_charge_id : void };

그런 다음 상용구 유형 가드 또는 trust-me-operator( as )가 필요합니다.

어설션 가드에도 더 많은 상용구가 필요합니다.

유형에 라이브러리 간 호환성이 필요하지 않은 경우 구조 유형을 사용하는 것이 좋습니다...
매우 인체공학적이지 않은 경우에도(위의 예 참조).

문자열 패턴 유형의 경우 A 라이브러리에 있는 경우

type stripeChargeIdRegex = /^ch_.+/;
type StripeChargeId = PatternOf<typeof stripeChargeIdRegex>;

B 라이브러리에는

//Extra dollar sign at the end
type stripeChargeIdRegex = /^ch_.+$/;
type StripeChargeId = PatternOf<typeof stripeChargeIdRegex>;

//Or,
type stripeChargeIdRegex =/^ch_[a-zA-Z0-9]$/;
type StripeChargeId = PatternOf<typeof stripeChargeIdRegex>;

//Or,
type stripeChargeIdRegex =/^ch_[A-Za-z0-9]$/;
type StripeChargeId = PatternOf<typeof stripeChargeIdRegex>;

두 라이브러리 모두 항상 두 라이브러리의 요구 사항을 충족하는 StripeChargeId 대한 문자열을 생성한다고 가정합니다. A 라이브러리는 유효성 검사와 함께 "게으른" 것입니다. 그리고 B 라이브러리는 유효성 검사가 "더 엄격"합니다.

그러면 좀 짜증납니다. 하지만 나쁘지 않습니다.
libraryB.stripeChargeIdRegex.test(libraryA_stripeChargeId) 를 typeguard로 사용할 수 있기 때문입니다. trust-me-operator( as )를 사용할 필요가 없습니다.

그러나 주장 보호를 위한 상용구는 여전히 필요합니다.

유형에 라이브러리 간 호환성이 필요하지 않은 경우 문자열 패턴 유형을 사용하는 것이 완벽하고 인체공학적입니다.

라이브러리 간 호환성이 필요한 경우 문자열 패턴 유형이 구조적 태그 유형보다 여전히 좋습니다! 내 말을 들어.

모델링되는 도메인이 잘 이해되면 여러 명의 격리된 라이브러리 작성자가 동일한 정규식을 작성하게 될 가능성이 매우 높습니다. 구조적 태그 유형을 사용하면 태그에 원하는 속성과 유형을 모두 쓸 수 있습니다.

모델링되는 모든 것에 대한 문자열 형식을 지정하는 표준 이 있는 경우 기본적으로 모든 라이브러리 작성자가 동일한 정규식을 작성하는 것이 보장됩니다! 다른 정규식을 작성하면 실제로 표준을 따르지 않습니다. 그들의 라이브러리를 사용하시겠습니까? 구조적 태그 유형을 사용하면 여전히 무엇이든 쓸 수 있습니다. (누군가가 관심을 가질 구조적 태그 유형 표준을 시작하지 않는 한? ㅋㅋ)

버전 간 호환성

평소와 같이 명목 유형은 버전 간 호환성 이 가장 낮 습니다.
오, 당신은 당신의 라이브러리를 패치 또는 마이너 버전에 부딪쳤습니까?
형식 선언이 여전히 동일합니까?
코드는 여전히 동일합니까?
아니요. 그들은 다른 유형입니다.

구조적 태그 유형은 태그 유형이 구조적으로 동일한 한 여러 버전(주요 버전 포함)에서 여전히 할당할 수 있습니다.

문자열 패턴 유형은 regex가 동일한 한 버전(주요 버전 포함) 간에 여전히 할당할 수 있습니다.

아니면 정규식이 동일한지 확인하기 위해 PSPACE-완전 알고리즘을 실행할 수 있습니까? 우리는 또한 정규식의 어떤 하위 클래스가 가장 일반적인지 결정할 수 있으며 이에 대해 최적화된 등가 알고리즘을 실행할 수 있습니다. 하지만 이는 많은 노력이 필요한 것처럼 들립니다.

Regex 하위 유형 검사는 있으면 멋지고 확실히 문자열 패턴 유형을 더 인체 공학적으로 사용할 수 있습니다. 범위 하위 유형 검사가 숫자 범위 유형 제안에 도움이 되는 것처럼.

[편집하다]
이 댓글에서,
https://github.com/microsoft/TypeScript/issues/6579#issuecomment -243338433

연결된 누군가,
https://bora.uib.no/handle/1956/3956

제목 "정규 표현식의 포함 문제"
[/편집하다]

상용구

TODO (하지만 우리는 문자열 패턴 유형이 가장 적은 양의 상용구를 가지고 있음을 알 수 있습니다)

리터럴 호출

TODO (하지만 문자열 패턴 유형이 리터럴 호출을 가장 잘 지원한다는 것을 알 수 있습니다)

문자가 아닌 호출

TODO (하지만 문자열 패턴 유형이 비문자 호출을 가장 잘 지원한다는 것을 알 수 있습니다)

https://github.com/microsoft/TypeScript/issues/6579#issuecomment -542405537에 대한 추가 정보

TypeScript는 교차의 인스턴스화에서 오류를 발생시킬 수 없으므로 이것은 최종 디자인의 일부가 아닙니다.

사람들이 교차로를 금지하려는 이유는 모르겠지만 금지하는 것이 말이 안 된다는 것은 전적으로 옳습니다.

따라서 문자가 아닌 모든 호출을 깨는 것입니까?

글쎄, 모든 비 리터럴 호출이 아닙니다.

declare function foo (arg : PatternOf</a+/>) : void;
function bar (arg : PatternOf</a+/>) : void {
  //non-literal and does not break.
  foo(arg);
}
bar("aa"); //OK
bar("bb"); //Error
bar("" as string); //Error, I know this is what you meant by non-literal invocation

function baz (arg : "car"|"bar"|"tar") : void {
  bar(arg); //OK
}

정규식과 일치한다는 것을 증명할 수 없는 문자가 아닌 호출을 중단하는 것이 반드시 나쁜 것은 아닙니다. 그것은 단지 유형 안전 문제입니다.

이는 문자가 아닌 호출이 실패하기 때문에 문자열 리터럴이 나쁘다고 말하는 것과 같습니다.
문자열 패턴 유형/정규식 검증 문자열 유형을 사용하면 무한한 수의 문자열 리터럴의 합집합을 정의할 수 있습니다.

문자가 아닌 사용은 재테스트 또는 주장이 필요합니다.

나는 그것을 전혀 문제로 보지 않는다.
지금은 명목/태그 유형과 동일합니다.
또는 문자열 리터럴을 예상하는 함수에 string 를 전달하려고 합니다.
또는 더 넓은 유형을 더 좁은 유형으로 전달하려고 합니다.

이 특별한 경우에 const ZipCode = /^\d\d\d\d\d$/; 및 ZipCode.test(s) 가 유형 가드 역할을 할 수 있음을 보여주었습니다. 이것은 확실히 인체 공학에 도움이 될 것입니다.

• 해결되고 있는 문제에는 더 나은 대안이 없습니다(아직 언어에 없는 그럴듯한 대안 포함).

글쎄, 나는 명목/구조 태그 유형이 더 나은 대안이 아니라는 것을 보여주길 바랍니다. 그들은 실제로 꽤 나쁩니다.

• 실제 코드베이스에서 의미 있는 빈도로 문제가 발생합니다.

어... 그 문제에 대해 다시 말씀드리겠습니다...

• 제안된 솔루션은 해당 문제를 잘 해결합니다.

제안된 문자열 패턴 유형은 꽤 괜찮은 것 같습니다.

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

당신의 견해는 명목/태그가 붙은 유형이 리터럴이 아닌 사용에 충분하다는 것입니다.
따라서 리터럴이 아닌 사용을 보여 주는 사용 사례는 명목/태그 유형이 다루기 때문에 충분하지 않습니다.

그러나 우리는 문자 그대로 사용하지 않더라도

• 명목/구조 태그 유형은 라이브러리/버전 호환성 문제로 어려움을 겪습니다.
• 명목/구조 태그 유형에 대한 상용구의 양이 문자열 패턴 유형에 대한 상용구보다 훨씬 많습니다.

또한, 제기된 문자 그대로의 사용 사례는 이메일 유효성 검사와 같은 어리석은 일을 시도하거나 충분히 정확하지 않은 정규식을 사용하기 때문에 만족스럽지 못한 것 같습니다.

테스트 작성 - 테스트 코드가 잘못된 입력을 많이 제공해야 하기 때문에 이것이 거의 대위법이지만 하드코딩된 입력이 의미가 있는 곳입니다.

좋은 사용 사례는 런타임 테스트를 작성하는 것이었습니다. 그리고 런타임 테스트를 위해 잘못된 입력을 많이 던져야 한다는 말이 맞습니다.

그러나 그것이 문자열 패턴 유형을 지원하지 않는 이유는 아닙니다. 특정 파일에서 유효한 입력을 테스트하고 실수로 잘못된 입력을 제공하려는 경우일 수 있습니다.

그러나 유형 가드 또는 trust-me-operator( as ) 또는 값 개체를 사용해야 하기 때문에 테스트가 미리 실패할 것이라는 것을 아는 대신 런타임 오류가 발생합니다. .

런타임 테스트에 trust-me-operator( as )를 사용하는 것은 잘못된 입력을 테스트하는 용도로만 예약해야 합니다. 유효한 입력을 테스트하려는 경우 리터럴을 명목/구조 태그 유형에 할당하기 위해 해킹이 필요하지 않은 것이 더 명확 합니다.

향후에 정규식을 변경하더라도 할당 가능성 문제로 인해 테스트가 실행되지 않는 것이 좋을 것입니다. 그들이 테스트의 모든 곳에서 우리를 as 한다면 테스트를 실행할 때까지 알 수 없습니다.

그리고 라이브러리 작성자가 자신의 라이브러리를 dogfood할 때 모든 곳에서 as 사용한다면... 다운스트림 소비자는 어떻습니까? 그들은 또한 모든 곳에서 as 를 사용하고 새 버전으로 업그레이드할 때 런타임 문제가 발생하지 않을까요?

문자열 패턴 유형을 사용하면 모든 곳에서 as 를 사용할 이유가 줄어들고 라이브러리 작성자와 다운스트림 소비자 모두 변경 사항을 깨는 것을 더 쉽게 알 수 있습니다.

(장황하지만 내 요점 중 일부가 통과되기를 바랍니다.)

또한 나는 많은 컴파일 타임 테스트를 작성합니다(TS 팀도 그렇게 한다는 것을 알고 있습니다).

특정 string 리터럴이 내 컴파일 타임 테스트에서 정규식 검사에 실패/통과하는지 테스트할 수 있다면 좋을 것입니다. 현재로서는 이러한 것들에 대한 컴파일 타임 테스트를 할 수 없으며 대신 런타임 테스트를 사용해야 합니다.

그리고 그것이 내 컴파일 시간 테스트에 실패/통과하면 다운스트림 소비자가 해당 문자열 리터럴(또는 유사한 문자열)을 사용하고 올바른 방식으로 작동할 것으로 기대할 수 있다는 확신을 갖게 됩니다.

이러다 바벨탑 사태로 순식간에 흘러가는 것 같은데...

이것은 실제로 명목/구조 태그 유형을 사용하는 경우에 더욱 그렇습니다. 위의 예에서 알 수 있듯이 라이브러리 간/버전 호환성이 끔찍합니다...

그러나 regexes/string-pattern 유형은 해당 문제에 빠지지 않을 적절한 기회 가 있습니다(표준화 및 정상적인 라이브러리 작성자 덕분에).

편집하다

스레드에서 일반적인 것은 이러한 정규식이 테스트 코드의 유효성을 검사하는 데 도움이 된다는 것입니다. 프로덕션 시나리오에서 코드가 하드코딩된 리터럴이 아닌 런타임 제공 문자열에 대해 실행되더라도 테스트 문자열이 " 옳은". 이것은 대신에 명목/태그/브랜드 문자열에 대한 인수로 보일 수 있습니다. 왜냐하면 유효성 검사 기능을 어느 쪽이든 작성하고 테스트의 이점은 철저하게 실행된다는 것을 알 수 있다는 것입니다(따라서 테스트 입력의 모든 오류는 개발 주기 초기에 플래그 지정).

아... 이 글을 쓰기 전에 먼저 다 읽었어야 했는데...

어쨌든 문자열 패턴 유형이 유용한 몇 가지 예가 있습니다.

HTTP 경로 선언 라이브러리

이 라이브러리를 사용하여 HTTP 경로 선언 개체를 빌드할 수 있습니다. 이 선언은 클라이언트와 서버 모두에서 사용됩니다.

/*snip*/
createTestCard : f.route()
    .append("/platform")
    .appendParam(s.platform.platformId, /\d+/)
    .append("/stripe")
    .append("/test-card")
/*snip*/

이것은 .append() 대한 제약 조건입니다.

• 문자열 리터럴만 해당(지금은 적용할 수 없지만 비 리터럴을 사용하면 경로 선언 빌더가 쓰레기가 됩니다)
• 선행 슬래시( / )로 시작해야 합니다.
• 후행 슬래시( / )로 끝나지 않아야 합니다.
• conlon 문자( : )를 포함할 수 없습니다. 매개변수용으로 예약되어 있습니다.
• 두 개 이상의 슬래시를 연속적으로 포함할 수 없습니다( // ).

지금은 오류가 발생하는 런타임 검사만 있습니다. 다운스트림 소비자가 Github README 또는 JSDoc 주석을 읽을 필요 없이 이러한 제약 조건을 따라야 합니다. 경로를 작성하면 빨간색 구불구불한 선이 표시됩니다.

기타 물건

16진수 문자열, 영숫자 문자열에 대한 정규식도 있습니다.

나도 이거 있는데,

const floatingPointRegex = /^([-+])?([0-9]*\.?[0-9]+)([eE]([-+])?([0-9]+))?$/;

나는 이것을 본다,

정수 - "3e5"를 잘못 거부합니다.

나는 또한 정수 정규식이 아니지만 floatingPointRegex .

function parseFloatingPointString (str : string) {
    const m = floatingPointRegex.exec(str);
    if (m == undefined) {
        return undefined;
    }
    const rawCoefficientSign : string|undefined = m[1];
    const rawCoefficientValue : string = m[2];
    const rawExponentSign : string|undefined = m[4];
    const rawExponentValue : string|undefined = m[5];

    const decimalPlaceIndex = rawCoefficientValue.indexOf(".");
    const fractionalLength = (decimalPlaceIndex < 0) ?
        0 :
        rawCoefficientValue.length - decimalPlaceIndex - 1;

    const exponentValue = (rawExponentValue == undefined) ?
        0 :
        parseInt(rawExponentValue) * ((rawExponentSign === "-") ? -1 : 1);

    const normalizedFractionalLength = (fractionalLength - exponentValue);
    const isInteger = (normalizedFractionalLength <= 0) ?
        true :
        /^0+$/.test(rawCoefficientValue.substring(
            rawCoefficientValue.length-normalizedFractionalLength,
            rawCoefficientValue.length
        ));
    const isNeg = (rawCoefficientSign === "-");

    return {
        isInteger,
        isNeg,
    };
}

이런 댓글도 있지만,

/**
    Just because a string is in integer format does not mean
    it is a finite number.

    ```ts
    const nines_80 = "99999999999999999999999999999999999999999999999999999999999999999999999999999999";
    const nines_320 = nines_80.repeat(4);
    //This will pass, 320 nines in a row is a valid integer format
    integerFormatString()("", nines_320);
    //Infinity
    parseFloat(nines_320);
    ```
*/

정규 표현식 생성자

재미있게도 RegExp 생성자는 정규식으로 검증된 문자열 유형의 이점을 누릴 것입니다!

바로 지금, 그것은,

new(pattern: string, flags?: string): RegExp

하지만,

new(pattern: string, flags?: PatternOf</^[gimsuy]*$/>): RegExp

TL;DR (꼭 읽어보세요, 제가 공을 많이 들였습니다 :cry: )

• 문자열 패턴 유형은 공칭/구조 태그 유형보다 인체공학적입니다.
  
  
  
  • 덜 상용구
  
  
• 문자열 패턴 유형은 명목/구조 태그 유형보다 바벨탑 상황이 될 가능성이 적습니다.
  
  
  
  • 특히 정규식 하위 유형 검사의 경우
  
  
• 문자열 패턴 유형은 string 유형의 대규모 유한/무한 하위 집합을 정의하는 가장 자연스러운 방법입니다.
  
  
  
  • 이 기능을 도입하면 사람들이 라이브러리의 유효한 문자열 형식에 대해 더 자세히 생각하게 될 수도 있습니다!
  
  
• 문자열 패턴 유형 (떨어져 ... 나 유행에 다시 연락하자
  
  
  
  • RegExp 생성자, 16진수/영숫자 문자열, 경로 경로 선언, 데이터베이스용 문자열 식별자 등
  
  

정규식은 왜 그렇게 나쁩니까?

다른 사람들이 제기한 많은 사용 사례는 기존 라이브러리에 맞게 문자열 패턴 유형을 도입하기를 원했습니다. TS 팀을 설득하지 못하는 것 같습니다.

종종 이러한 기존 라이브러리는 입력을 검증하기 위해 정규식을 많이 사용하지 않는 것 같습니다. 또는 정규식을 사용하여 간단한 유효성 검사를 수행합니다. 그런 다음 더 복잡한 파서를 사용하여 실제 유효성 검사를 수행합니다.

그러나 이것은 문자열 패턴 유형에 대한 실제 유효한 사용 사례입니다!

유효한 문자열 값의 상위 집합을 확인하는 문자열 패턴 유형

물론 / 시작하는 문자열은 / 로 끝나지 않고 연속적인 / 포함하지 않으며 : 포함하지 않는 문자열은 " HTTP 경로 정규식". 그러나 이것은 이 정규식을 전달하는 값 집합 이 유효한 HTTP 경로의

더 아래로 ? 가 사용되지 않았는지, # 가 사용되지 않았는지, 일부 문자가 이스케이프되었는지 등을 확인하는 실제 URL 경로 파서가 있습니다.

그러나 이 간단한 문자열 패턴 유형으로 우리는 이미 라이브러리 사용자가 직면할 수 있는 일반적인 문제의 큰 부류를 제거했습니다! 그리고 컴파일 타임에도 제거했습니다!

대부분의 사용자가 ? 가 쿼리 문자열의 시작이라는 것을 알 만큼 경험이 많기 때문에 사용자가 HTTP 경로에서 ? 를 사용하는 경우는 많지 않습니다.

나는 당신이 이미 이 사용 사례를 알고 있다는 것을 깨달았습니다.

이 스레드는 다양한 사용 사례를 의미합니다. 구체적인 예는 더 드물었다. 문제는 이러한 예제 중 많은 부분이 완전하지 않다는 것입니다. 유효한 입력을 거부하는 RegExp를 사용합니다.

따라서 제안된 많은 정규식은 "완벽"하지 않습니다.
하지만 유효한 입력을 거부하지 않는 한 괜찮겠죠?

잘못된 입력을 허용해도 괜찮습니다. 그렇죠?
런타임 동안 "실제" 파서를 가질 수 있기 때문에 전체 유효성 검사를 처리합니다.
그리고 컴파일 시간 검사는 다운스트림 사용자의 일반적인 문제를 많이 제거하여 생산성을 높일 수 있습니다.

유효한 입력을 거부하는 예제는 수정하기 쉬워야 유효한 입력을 거부하지 않지만 잘못된 입력을 허용합니다.

문자열 패턴 유형 및 교차

어쨌든 문자열 패턴 유형의 교차 유형은 매우 유용할 것입니다!

내 .append() 예제는 다음과 같이 작성할 수 있습니다.

append (str : (
  //Must start with forward slash
  & PatternOf</^\//>
  //Must not end with forward slash
  & PatternOf</[^/]$/>
  //Must not have consecutive forward slashes anywhere
  & not PatternOf</\/\//>
  //Must not contain colon
  & PatternOf</^[^:]+$/>
)) : SomeReturnType;

not PatternOf</\/\//> 도 가능합니다.
PatternOf</^((([/])(?!\3))|[^/])+$/> 하지만 이것은 훨씬 더 복잡합니다.

광범위한 데모에 대해 @AnyhowStep 에게 감사합니다. 책을 너무 많이 읽게 해서 비난하고 싶었지만 결과적으로는 많은 도움이 되었습니다!

나는 종종 문자열 매개변수로 가득 찬 내부 API를 입력하는 데 어려움을 겪으며 불가피하게 런타임에 발생하는 많은 조건문으로 끝납니다. 불가피하게 내 소비자는 예외를 원하지 않고 실패를 처리하는 특별한 방법을 원하기 때문에 이러한 패턴 검사를 복제해야 합니다.

// Today
function createServer(id: string, comment: string) {
  if (id.match(/^[a-z]+-[0-9]+$/)) throw new Error("Server id does not match the format");
  // work
}

// Nicer
function createServer(id: PatternOf</^[a-z]+-[0-9]+$/>, comment: string) {
  // work immediately
}

문자열과 패턴의 세계에서 일반 string 은 unknown 와 거의 동일하며 런타임 검사를 위해 많은 유형 안전을 제거하고 소비하는 개발자에게 불편을 줍니다.

언급된 일부 사용 사례의 경우 Regex의 작은 하위 집합만 필요합니다(예: 접두사 일치).

잠재적으로 이것은 Variadic Kinds #5453 및 문자열 리터럴 유형을 확산할 때 유형 유추와 같은 보다 일반적인 TS 언어 기능을 사용하여 수행할 수 있습니다.

미래의 추측:

const x: ['a', 'b', 'c'] = [...'abc'] as const;

type T = [...'def']; // ['d', 'e', 'f'];

type Guard<T extends string> =
  [...T] extends [...'https://', ...any[]] ? Promise<any> : never;

declare function secureGET<
  T extends string
>(url: T): Guard<T>;

const x = secureGET('https://a.com');
x.then(...) // okay

const z = secureGET('http://z.com');
z.then(...); // error

type NaturalNumberString<T extends string> =
  [...T] extends ('0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9')[] ? T : never;

언급된 일부 사용 사례의 경우 Regex의 작은 하위 집합만 필요합니다(예: 접두사 일치).

나는 여전히 이 + 몇 가지 다른 것들을 제공하는 내 제안 을 지지합니다. 기본적으로 별이 없는 언어 의 아주 작은 상위 집합은 여전히 ​​합리적으로 효율적으로 부분 집합과 평등을 확인할 수 있습니다. 그리고 지금까지 TS 팀의 가장 큰 우려인 임의 정규식의 성능 측면을 해결하려는 다른 제안을 본 적이 없습니다.

별표 없는 언어의 문제는 이름에서 알 수 있듯이 별표를 사용할 수 없기 때문에 URL과 같은 항목의 유효성을 검사하기 어렵습니다. 게다가 대부분의 사람들은 별을 원할 것이고 임의의 수의 반복 시퀀스를 사용하여 별을 에뮬레이트하므로 하위 집합을 확인하기가 어렵습니다.

그리고 대부분의 일반 DFA 표현 가능 정규식의 성능은 그렇게 나쁘지 않으며 하위/상위 집합에 대해 이를 확인할 수 있습니다.

그래도 일종의 * 을 얻을 수 있습니다.

const str : PatternOf</ab+c/> | PatternOf</ac/>

@TijmenW 내 제안을 조금 더 자세히 읽으십시오. 숨겨진 근거와 실제로 실용적으로 만드는 몇 가지 작은 기능이 있습니다. 별표 없는 문법을 지정하는 데 직접적으로 제한되지는 않지만 내 준고급 사용 사례에 실질적으로 유용할 만큼만 확장된 작은 상위 집합입니다. 특히, 개별 문자에 대해 starof ('a' | 'b' | ...) 를 수행할 수 있고 string 와 동등하게 starof UnionOfAllCodePoints (사실상 이론상 더 이상 기본 요소가 아님).

또한 정규 언어가 다른 정규 언어와 일치하는 부분 집합과 일치하는지 확인하는 것은 NP-완전하고 일반 하위 그래프 동형 문제 와 동일합니다. 이것이 바로 표준 정규 언어를 사용할 수 없는 이유이며, 이론적 계산 복잡성을 낮추기 위해 가능한 한 starof 를 제한하려고 한 이유입니다.

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

이것은 완전히 새로운 라이브러리이기 때문에 약간의 정보로 받아들일 수 있지만 https://github.com/ostrrowr/ts-json-validator 와 같은 라이브러리는 정규식 유형과 같은 것으로 훨씬 더 유용할 것입니다.

라이브러리의 목표는 다음과 같은 Typescript 유형/JSON 스키마 쌍 <T, s> 을 생성하는 것입니다.

1. 모든 유형의 것을 s 검증하기 위해 할당 할 수 있습니다 T
2. T 할당할 수 있는 가능한 한 적은 유형이 s 에 대해 실행될 때 유효성 검사에 실패합니다.

정규식 유형은 검증된 유형이 최소한 다음 키워드에 대해 더 엄격하도록 허용하여 (2)의 엄격성을 개선합니다.

• format
• patternProperties
• propertyNames

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

모든 Excel 인터페이스 라이브러리는 A1 또는 A5:B7 형식 유효성 검사를 사용할 수 있습니다.

속성 키 / 정규식 문자열 인덱서

일부 라이브러리는 속성 이름에 따라 개체를 처리합니다. 예를 들어 React에서 이름이 aria- 시작하는 모든 소품에 유형을 적용하려고 합니다.

interface IntrinsicElements {
    // ....
    [attributeName: /aria-\w+/]: number | string | boolean;
}

이것은 사실상 직교 개념입니다(Regex 속성 키를 추가하지 않고 Regex 유형을 추가할 수 있으며 그 반대의 경우도 마찬가지입니다).

나는 이것이 여기서 진행되는 모든 것과 약간 직교한다는 것을 알고 있지만 Wesley는 당신이 우리의 입력을 사용할 수 있다고 생각했습니다. 이것은 여러 가지 이유로 Fabric에서 계속 나타납니다. 컴포넌트 라이브러리로서 우리는 data- 및 aria- 속성을 포함하여 TypeScript에서 허용하는 React 컴포넌트 인터페이스를 정확하게 반영하는 컴포넌트 props 인터페이스를 향상시킬 수 있기를 원합니다. 그것 없이는 이러한 속성에 사용할 소비자 에게

우리가 도울 수 있는 일이 있다면 알려주세요! 😄

TS 놀이터 :

import * as React from 'react';

// Want to reflect the same aria- and data- attributes here that JSX compiler allows in this interface:
interface TestComponentProps {
    someProp?: number;
}

const TestComponent: React.FunctionComponent<TestComponentProps> = () => {
    return null;
}

const ConsumerComponent: React.FunctionComponent = () => {
    // The React component interface allows for 'data-' and 'aria-' attributes, but we don't have any typesafe way of
    // elevating that interface or instantiating props objects that allow the same attributes. We just want to be able to 
    // define component interfaces that match what the React component interface allows without opening it up to 'any' and 
    // giving up all type safety on that interface.
    const testComponentProps: TestComponentProps = {
        someProp: 42,
        'data-attribute-allowed': 'test'
    };

    return (
        <TestComponent
            someProp={42}
            // 'data-' and 'aria-' attributes are only allowed here:
            data-attribute-allowed={'data-value'}
            aria-attribute-allowed={'aria-value'}
            {...testComponentProps}
        />
    )
}

TODO: RegExp 유형의 이점을 얻을 수 있는 실제 라이브러리 함수와 사용할 실제 표현식을 식별하여 저희를 도와주세요.

크론 작업. (이것은 언급되지 않은 것에 매우 놀랐습니다)

^((\*|\d+((\/|\-|,){0,1}(\d+))*)\s*){6}$

여기에 2센트만 투자하면 됩니다. 저는 HTML id 속성으로 사용될 소품의 유효성을 검사하려는 React 프로젝트에서 작업하고 있습니다. 즉, 다음 규칙을 충족해야 하며 그렇지 않으면 예기치 않은 동작이 발생합니다.

1. 하나 이상의 캐릭터가 있어야 합니다.
2. 공백 없음

다시 말해:

interface Props {
  id: PatternOf</[^ ]+/>;
}

또 다른 예: '<namespace>/<name>[@<version>]' 형식으로 예상되는 문자열이 있는 성역 유형 식별자

사용 사례: Navigator.registerProtocolHandler() 와 같은 문자열 형식 DOM API

MDN 인용:

보안상의 이유로 registerProtocolHandler() 는 등록할 수 있는 체계를 제한합니다.

다음과 같은 경우 사용자 지정 체계를 등록할 수 있습니다.

• 사용자 정의 구성표의 이름은 web+
• 맞춤 구성표의 이름에는 web+ 접두사 뒤에 하나 이상의 문자가 포함됩니다.
• 사용자 정의 구성표는 이름에 소문자 ASCII 문자만 있습니다.

즉, Navigator.registerProtocolHandler() 는 잘 알려진 string 또는 사용자 정의 string 예상하지만 특정 스키마를 준수하는 경우에만 가능합니다.

CSSType 에 대한 CSS 사용자 정의 속성은 -- 접두사가 붙은 속성을 제외한 모든 속성에 대해 닫힌 유형을 제공하는 또 다른 사용 사례입니다.

interface Properties {
    // ....
    [customProperty: /--[a-z][^\s]*/]: number | string;
}`

관련 https://github.com/frenic/csstype/issues/63

이것이 구체화 유형과 동일한지 누군가 말해 줄 수 있습니까? https://github.com/microsoft/TypeScript/issues/7599

@gautam1168 이론적으로 문자열 유형을 구체적으로 구체화하는 부분 집합입니다. (물론 숫자 유형에는 고유한 관심사가 있습니다.)

언급된 일부 사용 사례의 경우 Regex의 작은 하위 집합만 필요합니다(예: 접두사 일치).

나는 여전히 이 + 몇 가지 다른 것들을 제공하는 내 제안 을 지지합니다. 기본적으로 별이 없는 언어 의 아주 작은 상위 집합은 여전히 ​​합리적으로 효율적으로 부분 집합과 평등을 확인할 수 있습니다. 그리고 지금까지 TS 팀의 가장 큰 우려인 임의 정규식의 성능 측면을 해결하려는 다른 제안을 본 적이 없습니다.

이 댓글에서,
https://github.com/microsoft/TypeScript/issues/6579#issuecomment -243338433

연결된 누군가,
https://bora.uib.no/handle/1956/3956

제목 "정규 표현식의 포함 문제"

하지만,

• 오른쪽 표현식이 1-모호하지 않으면 알고리즘이 정답을 제공합니다.
• 그렇지 않으면 정답이 나오거나 답이 없을 수 있습니다.

https://www.sciencedirect.com/science/article/pii/S0022000011001486

(물론 JS 정규식은 비정규식이다)

@AnyhowStep 효과 가 있을 수 있습니다. starof 제한을 해제하고 그에 따라 제한을 변경합니다. 수학이 조금 추상적이기 때문에 내가 제한을 특성화하는 더 좋은 방법을 부탁하고 구체적으로 실천에 적용 할 방식이 불분명 한 (그 유형을 사용하는 것 모두가 공식 언어로 잘 정통한 있습니다).

또한 별도로 starof 대한 더 나은 대안을 연산자로 사용하여 그런 종류의 것을 모델링하고 싶습니다.

https://github.com/Microsoft/TypeScript/issues/15480

궁금합니다. 정규식의 포함/포함을 결정할 수 있습니까? Wikipedia에 따르면 결정 가능합니다. 그러나 이것이 JS의 정규 표현식도 설명합니까? 표준 RE(예: 역참조)보다 더 많은 기능이 있다고 생각합니다. 결정 가능하다면 계산적으로 실현 가능한가?
이것은 이 기능에 영향을 미칩니다(좁히기):

if (Gmail.test(candidate)) {
    // candidate is also an Email
}

@nikeee Decidable은 이것이 현실적이기에 충분하지 않습니다. 2차 시간조차도 일반적으로 이 규모에서 너무 느립니다. TS는 아니지만 비슷한 문제에 대한 배경 지식이 있습니다.

역 참조에 직면하여 여전히 결정 가능하지만 더 나쁘지는 않더라도 기하 급수적일 가능성이 있다고 생각합니다. 다만, 교육받은 추측일 뿐입니다.

이것을 명확히 해 주셔서 감사합니다!

2차 시간조차도 일반적으로 이 규모에서 너무 느립니다.

이것이 내가 계산적으로 실현 가능한지 물은 이유이기도 하고, 그래서 나는 그렇지 않다고 생각합니다.

평등에도 동일하게 적용된다면 이 기능의 거의 모든 속성이 실행 불가능하지 않습니까? 제가 틀렸다면 정정합니다만, 남은 것은 회원가입뿐인 것 같습니다. 이것만으로는 유용하지 않을 것 같아요.

@nikeee 이 패턴은 문자 그대로 비교 대상이 되는 모든 유형의 모든 속성에 대해 검사된다는 점을 염두에 둘 가치가 있습니다. 그리고 regexp 속성이 있는 유형의 경우 regexp가 그 자체로 다소 복잡한 짐승인 다른 regexp와 일치하는 하위 집합과 일치하는지 여부를 계산 해야 합니다.

불가능한 것이 아니라 어려울 뿐이며 실현 가능하려면 제한적이어야 합니다. (예를 들어, JS regexps는 작동하지 않을 것입니다. 확장 가능하지 않을 뿐만 아니라 너무 유연합니다.)

편집: 나는 이것을 되풀이하고 싶습니다: 저는 명확히 하기 위해 TS 팀에 있지 않습니다 . CS 알고리즘 설계에 대한 배경 지식이 있습니다.

흠, 그래서 "일반적인" RegEx의 "제한된" 하위 집합만 지원할 수 있습니다. 사용 사례를 감안할 때 정규식은 지금까지 매우 간단했습니다. (색상, 전화 번호 등)

하위 집합만 지원하는 UX를 어떻게 설계할 수 있습니까? RegEx의 기능 X는 작동하지만 Y는 작동하지 않는다는 것이 사용자에게 명확하지 않을 수 있습니다.

음 ... "정규식"이라고 부르지 마십시오. 우선 시작하십시오. 아마도 "패턴 일치" 정도:see_no_ evil:. 하지만 네, 아마도 쉬운 일이 아닐 것입니다...

다음과 같은 비정규식 구문은 어떻습니까?

type TLD = 'com' | 'net' | 'org';
type Domain = `${string}.${TLD}`;
type URL = `${'http'|'https'}://${Domain}`;

const good: URL = 'https://google.com'; // ✔️
const bad: URL = 'ftp://example.com'; // ✖️ TypeError: 'ftp' is not assignable to type 'http' | 'https'

내 생각에 이것은 유형 시스템에 아주 잘 맞을 것입니다. 선택적 일치와 같은 항목에 대해 다른 구문을 추가할 수 있습니다.

type SubDomain = `${string}.`;
type Domain = `${SubDomain}?${string}.${TLD}`;

수량자, 탐욕적인 연산자에 대한 지원을 추가하면 개발자가 이것을 사용하려는 대부분의 사용 사례에 충분할 것이라고 생각하는 매우 강력한 무언가가 있습니다.

이 접근 방식이 더 사용자 친화적일 것이라고 생각합니다. 그러나 유형에 대한 산술 연산에 해당하는 것 같습니다.
https://github.com/microsoft/TypeScript/issues/15645#issuecomment -299917814 및 https://github.com/microsoft/TypeScript/issues/15794#issuecomment -301170109에 따르면 하지 않는 것이 디자인 결정입니다. 유형에 대한 산술.
내가 착각하는 것이 아니라면 이 접근 방식은 엄청난 유형을 쉽게 만들 수 있습니다. 고려하다:

type TLD = 'com' | 'net' | 'org' | 'ly' | 'a' | 'b' | 'c' | 'd';
type Foo = `${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}`;
type Bar = `${Foo}${Foo}${Foo}${Foo}${Foo}`

(이것은 구현에서 공용체 유형을 사용한다고 가정합니다. 다른/더 복잡한 구현에서 작동할 수 있음)

면책 조항: 저는 TS 팀의 일원이 아니며 TS에서 일하고 있지 않습니다. 그냥 내 2c.

@rozzzly @nikeee 몇 가지 작은 기능이 누락된 것이 제 제안의 핵심입니다 . 나는 정규식 리터럴 등의 의미에서 정규식이 아닌 정규 언어의 큰 부분 집합(공식 언어 개념)을 기반으로 했기 때문에 그보다 훨씬 덜 강력하지만 작업을 완료할 만큼 충분히 강력합니다.

이 접근 방식이 더 사용자 친화적일 것이라고 생각합니다. 그러나 유형에 대한 산술 연산에 해당하는 것 같습니다.

수학은 유형이 다른 유형의 하위 유형인지 여부를 확인하는 것은 주어진 형식 언어에 문자열이 포함되어 있는지 확인하는 것과 계산적으로 동일하다고 말합니다.

특히 도메인 유효성 검사는 TLD/ 공개 접미사 유효성도 확인하는 경우 실제로 수행하기 매우 복잡한 작업입니다. RFC에 따른 일반 도메인 자체는 /[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)+/ + 최대 255자만큼 간단하지만, 위의 정규 표현식에서 보여주듯이 전체 일반 문법을 사용하지 않는 한 이마저도 입력하기가 매우 복잡합니다. @rozzzly 또는 내 제안의 문자열만 사용하여 프로그래밍 방식으로 매우 간단하게 유형을 생성할 수 있지만(독자에게 연습용으로 남겨두겠습니다) 최종 결과는 여전히 다소 복잡합니다.

@isiahmeadows

그것은 몇 가지 작은 기능이 빠진

이 전체 스레드를 마지막으로 읽은 것은 1년이 훨씬 넘었습니다. 쉬는 시간에 알림을 보고 @rugk님 의 _"글쎄 ... "정규식"이라고 부르지 마세요 -

...위의 regexp가 보여주는 것처럼 완전한 정규 문법을 사용하지 않는 한 이것은 입력하기가 매우 복잡합니다. @rozzzly 또는 내 제안의 문자열만 사용하여 프로그래밍 방식으로 매우 간단하게 유형을 생성할 수 있지만(독자에게 연습용으로 남겨두겠습니다) 최종 결과는 여전히 다소 복잡합니다.

내 생각에, 내가 제안한 것과 같은 제한된 패턴 일치를 위한 일부 기능은 매우 단순하고 _필연적으로 엄격하지 않은_ 엄격한 입력에 매우 유용할 것입니다. 내가 준 예는 정확하지 않으며 컴파일러를 폭파시키지 않을 것입니다.

그러나 @nikeee 와 당신이 모두 지적했듯이 이것은 위험한 극단으로 취해질 수 있습니다. 공용체만 지원하는 가장 순진한 구현을 가정합니다. 누군가 다음을 포함하는 @types/some-popular-project 대한 업데이트를 게시하여 모든 사람의 하루를 망칠 것입니다.

type MixedCaseAlphaNumeric = (
    | 'a'
    | 'b'
    | 'c'
    // and so on
);

type StrWithLengthBeteen1And64<Charset extends string> = (
    | `${Charset}`
    | `${Charset}|${Charset}`
    | `${Charset}|${Charset}|${Charset}`
    // and so on
);

function updatePassword(userID: number, password: StrWithLengthBetween1And64<MixedCaseAlphaNumeric>): void {
    // ...
}

그것을 관점에서 보면, 그 연합은 다음과 같이 구성됩니다. 관찰 가능한 우주의 원자 보다 더 많은 별개의 유형.

이제, 나는 끔찍하게 긴 할당 가능성 오류를 보았지만 그에 대한 (잘리지 않은) 오류를 상상해보십시오.

Type '"😢"' is not assignable to type '"a"|"b"|"c"..........."'.ts(2322)'

예.. 거기에 몇 가지 문제가 있습니다.

@rozzzly 그 유형이 TupleWithLengthBeteen1And64<Charset> 와 다른 점(가능성 측면에서)은 무엇입니까?
컴파일러는 모든 유형을 정규화된 형식으로 확장하도록 강요되지 않으며, 그렇게 하면 상당히 정상적인 유형에서 빠르게 폭발할 것입니다.
"3과 1024 사이의 정수"(메시지 버퍼 할당 길이를 생각함)라도 범위를 벗어난 것으로 간주되는 경우 이 문제가 현재 typescript에서 의미가 있다고 생각하지 않습니다.

@simonbuchan 최소한 접두사와 접미사 유형이 존재해야 합니다. 이는 많은 DOM 라이브러리와 프레임워크에 필요합니다.

나는 이것이 죽도록 두들겨 맞았고 몇 가지 좋은 제안이 이미 주어졌다는 것을 알고 있습니다. 그러나 나는 일부 사람들이 약간 흥미롭게 생각할 수 있는 추가 항목을 추가하고 싶었습니다.

역 참조에 직면하여 여전히 결정 가능하지만 더 나쁘지는 않더라도 기하 급수적일 가능성이 있다고 생각합니다. 다만, 교육받은 추측일 뿐입니다.

역 참조는 regexp가 컨텍스트 프리 문법의 상위 집합인 컨텍스트에 민감한 문법을 ​​설명하도록 만들 수 있습니다. 그리고 CFG에 대한 언어 평등은 결정할 수 없습니다. 따라서 선형 제한 자동 장치에 해당하는 CSG의 경우 더 나쁩니다.

DFA로 변환할 수 있는 모든 정규 표현식이 정규 표현식(concat, union, star, 교집합, 보수 등)에 사용된다고 가정하면 정규 표현식을 NFA로 변환하는 것은 O(n)이며 2의 곱을 얻습니다. NFA는 O(m*n)이고 수락 상태에 대한 결과 그래프를 순회하는 것은 O(m*n)입니다. 따라서 두 정규 정규식의 언어 동등성/부분집합을 확인하는 것도 O(m*n)입니다.

문제는 여기서 알파벳이 정말 크다는 것입니다. 교과서는 일반적으로 DFA/NFA/정규 표현식에 대해 이야기할 때 크기가 1-5인 알파벳으로 제한됩니다. 그러나 JS 정규 표현식을 사용하면 모든 유니코드가 알파벳으로 사용됩니다. 물론, 평등/부분집합 테스트를 위해 희소 배열 및 기타 영리한 해킹 및 최적화를 사용하여 전환 함수를 표현하는 효율적인 방법이 있을 수 있습니다...

정규 대 정규 할당에 대한 유형 검사를 다소 효율적으로 수행할 수 있다고 확신합니다.

그런 다음 모든 비정규 할당에는 명시적 형식 어설션만 필요할 수 있습니다.

나는 최근에 작은 유한 자동 장치 프로젝트에서 일했기 때문에 정보가 여전히 내 마음에 신선합니다 =x

내가 착각하는 것이 아니라면 이 접근 방식은 엄청난 유형을 쉽게 만들 수 있습니다. 고려하다:

type TLD = 'com' | 'net' | 'org' | 'ly' | 'a' | 'b' | 'c' | 'd';
type Foo = `${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}${TLD}`;
type Bar = `${Foo}${Foo}${Foo}${Foo}${Foo}`

(이것은 구현에서 공용체 유형을 사용한다고 가정합니다. 다른/더 복잡한 구현에서 작동할 수 있음)

재미있게도 이것이 바로 새로운 템플릿 문자열 리터럴 유형으로 가능한 것입니다. 이 경우는 공용체 유형에 대한 임계값을 가짐으로써 피할 수 있습니다.

@AnyhowStep JS 역참조는 유일하게 상황에 맞는 프로덕션(그리고 상당히 간단하고 제한된 것 - 최대 9개의 그룹만 이와 같이 참조할 수 있음)이며 나머지 정규 표현식 문법은 규칙적이므로 의심됩니다. 결정 가능합니다. 그러나 그럼에도 불구하고 우리는 그것이 어떤 의미에서든 실용적이지 않다는 데 동의할 수 있다고 생각합니다. 🙂

편집: 정확도

@rozzzly의 이 댓글 은 야간에 TS 4.1.0에서 작동함을 확인했습니다!

type TLD = 'com' | 'net' | 'org';
type Domain = `${string}.${TLD}`;
type Url = `${'http'|'https'}://${Domain}`;

const success: Url = 'https://example.com';
const fail: Url = 'example.com';
const domain: Domain = 'example.com';

플레이그라운드에서 시도해 보고 fail 에 컴파일 시간 오류가 있는지 확인하세요 🤩

업데이트 : 이 기능을 조금 사용해 본 후에는 많은 사용 사례를 다루지 않을 것입니다. 예를 들어, 16진수 색상 문자열에는 작동하지 않습니다.

type HexChar = '0' | '1' | '2' | '3' | '4' | '5' | '6'| '7' | '8' | '9' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F';
type HexColor = `#${HexChar}${HexChar}${HexChar}${HexChar}${HexChar}${HexChar}`;
let color: HexColor = '#123456';

오늘은 "표현하기에는 너무 복잡한 공용체 유형을 생성하는 표현식(2590)"으로 실패합니다

@rozzzly의 이 댓글 은 야간에 TS 4.1.0에서 작동함을 확인했습니다!

type TLD = 'com' | 'net' | 'org';
type Domain = `${string}.${TLD}`;
type Url = `${'http'|'https'}://${Domain}`;

const success: Url = 'https://example.com';
const fail: Url = 'example.com';
const domain: Domain = 'example.com';

플레이그라운드에서 시도해 보고 fail 에 컴파일 시간 오류가 있는지 확인하세요 🤩

이것은 인덱스에 적용할 수 있다면 우리 대부분이 UX 라이브러리에서 직면하는 데이터 또는 아리아 문제를 해결할 수 있습니다.

기본적으로 이것은 TS가 문자열만 허용하기 때문에 작동하지 않습니다. | 숫자. 이것은 본질적으로 문자열이므로 활성화할 수 있습니까?
https://www.typescriptlang.org/play?target=99&ts=4.1.0-dev.20201001#code/LAKALgngDgpgBAEQIZicgzgCzgXjgAwBIBvAcgBMUkBaUgXxPTACcBLAOwHM78BuUDmBjMAZkgDG8AJIAVGEzjFQcFXADalVBkwAFZgHsoALmRakWALpGmbLvxB1QocfvYL0AV3GT06I3Fl5MFxFCipqISZSI1JIsHpeIA

_업데이트_: 이 기능을 조금 사용해 본 후에는 많은 사용 사례를 다루지 않을 것입니다. 예를 들어, 16진수 색상 문자열에는 작동하지 않습니다.

type HexChar = '0' | '1' | '2' | '3' | '4' | '5' | '6'| '7' | '8' | '9' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F';
type HexColor = `#${HexChar}${HexChar}${HexChar}${HexChar}${HexChar}${HexChar}`;
let color: HexColor = '#123456';

오늘은 "표현하기에는 너무 복잡한 공용체 유형을 생성하는 표현식(2590)"으로 실패합니다

릴리스 정보에 이 제한 사항에 대한 언급이 있었습니다. 가능한 모든 유효한 조합의 목록을 생성합니다. 이 경우 16,777,216(즉, 16^6) 멤버가 있는 공용체를 생성합니다.

이것은 좋은 아이디어입니다... Igmat는 2016년에 종이로 보기에도 괜찮아 보이는 몇 가지 놀라운 게시물을 만들었습니다.

내 함수에 전달된 개체 리터럴의 키가 유효한 CSS 클래스 이름인지 확인하고 싶었기 때문에 이것을 찾았습니다. 런타임에 쉽게 확인할 수 있습니다... 하지만 제가 보기에는 typescript가 컴파일 시간에 이 작업을 수행할 수 있어야 한다는 사실이 너무도 분명해 보입니다. 특히 객체 리터럴을 하드 코딩하고 typescript가 다음을 알아낼 필요가 없는 상황에서는 더욱 그렇습니다. MyUnionExtended이국적유형은 SomeArbitraryRegexType을 충족합니다.

언젠가는 더 생산적인 기여를 할 수 있을 만큼 지식을 갖추게 될 것입니다./

@rozzzly의 이 댓글 은 야간에 TS 4.1.0에서 작동함을 확인했습니다!

우와. 나는 솔직히 이것이 구현되는 것을 기대하지 않았습니다. 적어도 조만간은 아닙니다.

@chadlavi-casebook

릴리스 정보에 이 제한 사항에 대한 언급이 있었습니다. 가능한 모든 유효한 조합의 목록을 생성합니다. 이 경우 16,777,216(즉, 16^6) 멤버가 있는 공용체를 생성합니다.

성능 문제가 되기 전에 해당 조합이 얼마나 커질 수 있는지 궁금합니다. @styfle 의 예는 그

@thehappycheese

내 함수에 전달된 객체 리터럴의 키가 유효한 CSS 클래스 이름인지 확인하고 싶었습니다.

현재 구현으로는 불가능하다고 자신합니다. 수량자와 범위에 대한 지원이 있는 경우 BEM 스타일 클래스 이름에 대한 유효성 검사를 받을 수 있습니다. 이에 대한 표준 js 정규식은 _너무_ 끔찍하지 않습니다.
^\.[a-z]([a-z0-9-]+)?(__([a-z0-9]+-?)+)?(--([a-z0-9]+-?)+){0,2}$
당신은 또한 앵커를 버릴 것인데, 그 이유는 구현이 의미하는 바와 같이 종단 간 일치이거나 아무것도 아니므로 ^ 및 $ 가 암시되기 때문입니다. 이제 유효한 CSS 선택기의 좁은 하위 집합에 대한 비교적 간단한 정규식입니다. 예: ಠ_ಠ 는 유효한 클래스 이름입니다. 농담이 아냐.

죄송합니다. 나는 이것을해야했다.

TypeScript에서 일반 언어를 구현했습니다.

• 놀이터 #1 , 1의 수는 3으로 나눌 수 있지만 2로 나눌 수 없습니다.

• 놀이터 #2 , 길이가 6인 16진 문자열

더 정확하게는 TS 4.1을 사용하여 간단한 결정론적 유한 오토마톤을 구현했습니다.

내 말은, 우리는 이미 TS에서 튜링 기계를 구현할 수 있습니다. 따라서 DFA와 PDA는 그에 비해 "쉽습니다".

그리고 템플릿 문자열은 이것을 더 유용하게 만듭니다.

핵심 유형은 실제로 간단하고 < 30 LOC에 적합합니다.

type Head<StrT extends string> = StrT extends `${infer HeadT}${string}` ? HeadT : never;

type Tail<StrT extends string> = StrT extends `${string}${infer TailT}` ? TailT : never;

interface Dfa {
    startState : string,
    acceptStates : string,
    transitions : Record<string, Record<string, string>>,
}

type AcceptsImpl<
    DfaT extends Dfa,
    StateT extends string,
    InputT extends string
> =
    InputT extends "" ?
    (StateT extends DfaT["acceptStates"] ? true : false) :
    AcceptsImpl<
        DfaT,
        DfaT["transitions"][StateT][Head<InputT>],
        Tail<InputT>
    >;

type Accepts<DfaT extends Dfa, InputT extends string> = AcceptsImpl<DfaT, DfaT["startState"], InputT>;

어려운 부분인 자동 장치를 지정하는 것입니다.

하지만 누군가 TypeScript DFA™ 생성기에 대한 정규식을 만들 수 있다고 확신합니다...

또한 "길이 6의 16진 문자열" 예제에서 못생긴 해커를 사용하여 정규식과 일치하는 문자열만 허용하도록 함수 매개변수를 만들 수 있음을 강조하고 싶습니다.

declare function takesOnlyHex<StrT extends string> (
    hexString : Accepts<HexStringLen6, StrT> extends true ? StrT : {__err : `${StrT} is not a hex-string of length 6`}
) : void;

//OK
takesOnlyHex("DEADBE")

//Error: Argument of type 'string' is not assignable to parameter of type '{ __err: "DEADBEEF is not a hex-string of length 6"; }'.
takesOnlyHex("DEADBEEF")

//OK
takesOnlyHex("01A34B")

//Error: Argument of type 'string' is not assignable to parameter of type '{ __err: "01AZ4B is not a hex-string of length 6"; }'.
takesOnlyHex("01AZ4B")

여기 보너스 놀이터가 있습니다 . 정규식 /^hello .*/ 구현합니다.

그리고 또 다른 놀이터 ; 정규식 / world$/ 구현합니다.

마지막 예인 Playground ; 이것은 부동 소수점 문자열 정규식입니다 !

@AnyhowStep 글쎄, 나는 당신의 DFA 아이디어를 사용하여 간단한 정규식 [abc]{4} 를 구현했습니다. 이는 문자 abc가 누락되었지만 정확히 길이가 4임을 의미합니다. (aaaa, abcc, bbcc 등...).
운동장

https://cyberzhg.github.io/toolbox/min_dfa?regex=ZCgoYmQqYiopKmMpKg==

https://github.com/CyberZHG/toolbox

의지력이 더 있었다면 위와 같은 것을 가져와 정규식을 TS DFAs™로 바꾸는 데 사용할 것입니다. lol

좋아요, 방금 프로토타입을 만들었습니다.

https://glitch.com/~sassy-valiant-heath

[편집] https://glitch.com/~efficacious-valley-repair <-- 이것은 더 복잡한 정규식에 대해 더 나은 출력을 생성합니다.

[편집] Glitch는 너무 오랫동안 비활성 상태인 무료 프로젝트를 보관할 것 같습니다. 여기 파일이 있는 git repo가 ​​있습니다.
https://github.com/AnyhowStep/efficacious-valley-repair/tree/main/app

1단계, 여기에 정규식을 입력합니다.

2단계, 변환을 클릭하고,

3단계, 생성된 TS 플레이그라운드 URL을 클릭하고,

4단계, InLanguage_0 까지 아래로 스크롤합니다.

5단계, 입력 값으로 재생,

변환의 무거운 작업을 수행한 https://www.npmjs.com/package/regex2dfa의 작성자인 @kpdyer에게 감사 를 전합니다.

조금 더 강력한 것이 필요한 사람을 위해 튜링 머신이 있습니다 😆

운동장

이 스레드는 너무 길어서 읽을 수 없으며 많은 주석이 템플릿 리터럴 유형으로 처리되거나 주제에서 벗어납니다. 이 기능으로 활성화할 수 있는 나머지 사용 사례에 대해 논의하기 위해 새로운 문제 #41160을 만들었습니다. 여기에서 유형 시스템 파서에 대해 계속 논의하십시오 😀