Typescript: 提案：正規表現で検証された文字列型

ええ、私はこれがDefinitelyTypedを介してコーミングするのを見ました。 サービスレイヤーで

主な問題は次のとおりです。

• これらをうまく構成する方法は明確ではありません。 "cat" 、 "dog" 、および"fish"コンマ区切りリストが必要な場合は、 /dog|cat|fish(,(dog|cat|fish))*/ように記述する必要があります。
  
  
  
  • "cat" 、 "dog "、および"fish"文字列リテラル型を記述する型がすでにある場合、それらをこの正規表現に統合するにはどうすればよいですか？
  
  
  • 明らかにここには繰り返しがありますが、これは望ましくありません。 おそらく、前の問題を修正すると、これが簡単になります。
  
  
• 非標準の拡張機能は、この種の問題を引き起こします。

これに関する巨大な+ 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-validatedstring types_でどのように機能しますか？

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は_正規表現で検証された文字列型_です。

編集：この問題は多項式時間で解決できるようです（正規表現の包含問題を参照）。

TypeStyleにも役立ちます： https ：

JSXでは、 @ RyanCavanaughと私は、人々がaria- （および場合によってはdata- ）属性を追加するのを見てきました。 誰かが実際にキャッチオールとしてDefinitelyTypedに文字列インデックス署名を追加しました。 このための新しいインデックス署名が役立つでしょう。

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

設計提案

そこ開発者はその後、単なる文字列より指定された値を必要とするとき例がたくさんありますが、単純な文字列リテラル例えばCSSの色、電子メール、電話番号、郵便番号、の和集合としてそれらを列挙することはできません闊歩拡張子さえなどJSONスキーマ仕様は、どの一般JSONオブジェクトのスキーマを記述するために使用されるのは、TSタイプシステムの観点からregex-validated string typeおよびregex-validated string type of indexと呼ばれる可能性のあるpatternおよびpatternPropertiesを持っています。

目標

開発者に、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
}

インデックスタイプのタイプgurard

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 string変数への割り当ても制限する必要があります。これは、コンパイル時に正規表現と一致するという保証がないためです。

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の単純なケースについては、インデックスタイプのタイプgurardを参照してください。
しかし、もっと複雑なケースがあるかもしれません：

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タイプは実際には異なるため、correcltyがそれらの和集合と共通部分を処理する方法のルールが必要です。

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型は、通常の型と同じようにジェネリックで使用できます。
以下のような制約のあるジェネリックスの場合、 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 = { ... };

しかし、2番目はすでに無効でしたが、別の理由（型宣言が間違っていた）が原因です。
したがって、この型がregex-validated場合に備えて、型と同じ名前の変数の宣言を制限する必要があります。

PS

私がおそらく見逃したことを自由に指摘してください。 この提案が気に入ったら、それをカバーするテストを作成して、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

したがって、正規表現はあまり読みにくく、すべての場所にコピーする必要があるため、ユーザーが簡単に間違える可能性があることを除けば、emitには影響せず、問題ないように見えます。 しかし、この特定のケースでは、 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放出をわずかに変更する必要があります。

@DanielRosenwasser 、この提案に対するフィードバックをお願いします。 また、可能であれば、ここで参照されているテストについてもどうでしょうか。
この機能の実装を本当に手伝いたいのですが、時間がかかります（ tscは非常に複雑なプロジェクトであり、内部でどのように機能するかを理解するために作業する必要があります）。この提案を実装する準備ができているか、別の言語設計ビジョンまたはその他の理由により、この方法で実装されたこの機能を拒否します。

ねえ@Igmat 、私が最初に尋ねるべきだったことがいくつかあると思います

そもそも、なぜ放出するのに何らかの変更が必要なのか、私にはまだわかりません。また、タイプに基づいた放出は受け入れられないと思います。 ここで私たちの非目標をチェックしてください。

私が提起すべきもう1つの問題は、後方参照を使用する正規表現の問題です。 私の理解（および経験）は、正規表現の後方参照により、入力に対して指数関数的な時間でテストを強制的に実行できることです。 これはコーナーケースですか？ たぶん、でもそれは私が一般的に避けたいものです。 エディターのシナリオでは、ある場所でのタイプチェックにかかる時間が最小限であるため、これは特に重要です。

もう1つの問題は、TypeScriptコンパイラが実行されるエンジンに依存するか、これらを実行するためにカスタム正規表現エンジンを構築する必要があることです。 たとえば、TC39は、 .が改行と一致できるように、新しいsフラグを含めるように移動しています。 ESXXXXと、これをサポートする古いランタイムとの間には不一致があります。

@ igmat-実行時に正規表現を間違いありません。 ただし、この機能が役立つために必要だとは思いません（ @DanielRosenwasserが言ったことからすると、とにかく承認されない可能性があります）。 あなたが言った

ただし、文字列から正規表現で検証されたタイプへのナローイングを処理して、便利にする必要もあります。

これは、動的文字列から正規表現で検証されたタイプに絞り込む場合にのみ当てはまると思います。 これは非常に複雑になります。 この単純な場合でも：

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

タイプが一致するかどうかはわかりません-数値が負の場合はどうなりますか？ そして、正規表現がより複雑になるにつれて、それはどんどん乱雑になります。 これが本当に必要な場合は、「型補間： 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 、私は設計目標を注意深く読みました。あなたを正しく理解していれば、問題は非目標＃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
}

ご覧のとおり、コードはほとんど同じです。これは、正規表現の一般的な単純な使用法です。 しかし、2番目のケースははるかに表現力があり、正規表現で検証されることを意図した変数に割り当てる前に文字列をチェックするのを忘れるなど、ユーザーが誤って間違えるのを防ぎます。
2つ目は、このような型の絞り込みがないと、通常、インデックスで正規表現で検証された型を使用できないことです。ほとんどの場合、このようなインデックスフィールドは、リテラルで実行できるように実行時にチェックできない変数で機能するためです。 。

@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わかりました、もう1つアイデアがあります。 このような構文はどうですか？

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 、あなたの2番目の問題について-私の提案ではコンパイラはリテラルに対してのみ正規表現を実行し、誰かがこのようなことをするようには思われないので、私はそれが起こるとは思わない：

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

とにかく、リアルタイムのパフォーマンスに影響を与えるためにリテラルの長さをテストし、一部のエディターシナリオでこの状況に直面しているときにユーザーが確認できない場合にユーザーに警告するヒューリスティックを作成できますが、ユーザーがコンパイルするときに確認します。事業。 または、他の回避策がある可能性があります。

3番目の質問については、すべてが正しく理解されているかどうかはわかりませんが、実装が異なる場合は、 tsconfigからtarget応じて正規表現エンジンを選択する必要があるようです。 さらに調査が必要です。

@DanielRosenwasser何か考えはありますか？ 😄最初の提案と最後の提案について。 2番目の概要をもっと詳しく説明する必要があるかもしれませんね。

@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

ただし、このメカニズムをプリミティブを超えて非プリミティブ型に拡張するのは多すぎると思います。
1つのポイントとして、 @ DanielRosenwasserが提起した問題（さまざまな正規表現エンジンの実装について）が拡大されます

@zspitz有望に見えますが、関数がルールによって制限されておらず、TSに複雑すぎる式や利用できないリソースに依存する式を計算させるため、コンパイラのパフォーマンスに大きな影響を与える可能性があります。コンパイル時に。

@Igmat

機能はルールによって制限されていないため

具体的な例をいくつか考えていますか？ おそらく、検証構文を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とWeb開発にとって

拡張性とタイプの放出が他の機能の邪魔にならないようにすることに同意します。 これらの側面に明確な道筋がない場合は、後でそれらを実装してください。

文字列ではなくUUID型を探しているので、ここに到着しました。したがって、この場合、文字列を定義する正規表現があると便利です。+型の有効性を確認する方法（Email.testの例）も役立ちます。

@skbergamもう一度自分で実装しようとしています。 しかし、TSプロジェクトは本当に巨大で、私も仕事をしているので、ほとんど進展がありません（私はこの新機能のテストを作成することしかできませんでした）。 誰かがTSの拡張についてより多くの経験を持っているなら、どんな助けも大いにありがたいです...

興味深いことに、これにより名目型が効果的に作成されます。これは、2つの同一でない正規表現の間にサブタイプ/割り当て可能性の関係を確立できないためです。

@RyanCavanaugh以前の@maiermicがコメントしました

編集：この問題は多項式時間で解決できるようです（正規表現の包含問題を参照）。

しかし、それは十分ではないかもしれませんか？ 多くの正規表現関係がないことを確かに望んでいますが、あなたは決して知りません。

型チェックに関して、正規表現を複製するのが好きではなく、 typeof constが十分でない場合（.d.tsファイルなど）、TSはvalueof eについてどのように感じますか？ eがリテラルである場合、 eのリテラル値、それ以外の場合はエラー（および、 undefinedようなものを出力します）？

@maxlkこれもトピックから外れていますが、正規表現を取得して、それ以外の場合は有効な入力の末尾のコンマと一致しないように改善しました：テストhttps://regex101.com/r/AuyP3g/1で/^((dog|cat|fish)(,(?=\b)|$))+$/ 。 これは、コンマの後の単語文字に正の先読みを使用し、DRYの方法で再検証する前に強制します。

やあ！
これの状況はどうですか？
近い将来、この機能を追加しますか？ ロードマップでこれについて何も見つかりません。

@lgmat lib.d.ts使用可能な定義のみを使用して、構文を1行の矢印関数に制限するのはどうですか？

それらの素晴らしい改善は利用できますか？ 多分少なくともアルファリリースでは？

正規表現で検証された型はテストの作成に最適であり、ハードコードされた入力の検証は優れています。

+1。 私たちのユースケースは非常に一般的であり、「dd / mm / YYYY」のような文字列の日付形式が必要です。

提案されているように、それは非常にクールな機能ですが、可能性はありません。

• 出力は常にstingです（コンパイル時はチェックされますが）、構造化オブジェクトを取得する方法はありません
• 文法はregexpが実行できるものに制限されており、多くのことを実行できません。正規表現の問題は、正規表現であり、結果がツリーではなくリストであり、任意の長いネストされたレベルを表現できないことです。
• パーサーはタイプスクリプト文法で表現する必要がありますが、これは制限されており、拡張できません。

より良い方法は、＃21861で提案されているように、解析をアウトソーシングしてプラグインに出力することです。この方法では、学習曲線が急になるという代償を払って、上記のすべてが問題になることはありませんが、ちょっと！ その上に正規表現チェックを実装できるため、元の提案は引き続き有効であり、より高度な機械によって提案されます。

だから私が言ったように、より一般的な方法はどんなリテラルのためのカスタム構文プロバイダーでしょう：＃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使用可能な定義のみを使用して、構文を1行の矢印関数に制限するのはどうですか？

@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

ただし、このメカニズムをプリミティブを超えて非プリミティブ型に拡張するのは多すぎると思います。

これで私が目にする主な問題は、セキュリティ上の懸念です。悪意のあるコードを想像してみてください。バッファを使用して、タイプをチェックしながらユーザーのメモリを取得します。 この周りに多くのサンドボックスを実装する必要があります。 私はむしろ2つの異なる解決策を見たいと思います。1つは文字列用で、もう1つは数字用です。

これを悪意を持って使用できる唯一の方法は、バックトラック式を作成することであるため、RegExpは一部の拡張機能の影響を受けません。 そうは言っても、一部のユーザーは意図せずにそれを行う可能性があるため、何らかの保護が必要です。 それをする最良の方法はタイマーだと思います。

1つのポイントとして、 @ DanielRosenwasserが提起した問題（さまざまな正規表現エンジンの実装について）が拡大されます

確かに、これは悪いことですが、コードベースに必要なregExpの「最新の」部分を指定することで解決できます。 デフォルトでは、すべてのノードで機能する通常の（ES3ですか？）正規表現になり

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は、指示がない限り、高度な正規表現を評価しません。 しかし、何が起こっているのか、高度な正規表現チェックを有効にする方法を説明して、警告を出す必要があることをお勧めします。

ユーザーが高度なフラグでフラグを有効にしていて、ノードがそれをサポートしている場合。

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がこれほど大きな可能性を秘め、何十もの素晴らしい提案をしているのを見るのは本当に残念ですが、開発者からはあまり注目されていません…

元の提案は、 Emitの概要を除けば良かったので、実際には必要ないので、提案を妨げることはありません。

対処しようとしている問題は、正規表現リテラル（文字列および数値リテラルと実質的に同等であるため難しいことではありません）と型演算子patternof （ typeofと同様）を導入することで解決できます。 keyof ）。これは正規表現リテラル型を取り、_validatedstring_型を返します。 これはそれがどのように使われることができるかです：

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最初の提案に取り組んでいたとき、私は追加の型演算子を使用したそのような解決策について考えていませんでした。

これはより冗長に見えますが、タイプによって引き起こされる放出の影響を取り除くこのアプローチが好きです。

そしてこれは、（あなたが提案するように）新しいキーワードの追加をスキップするためにこの提案を拡張する方法を私に導きました-IMOはすでにかなりの量を持っており、型システムからの影響を放出していません（私の提案のように）。

4つのステップが必要です。

1. regexp-validated string literalタイプを追加します。
   TypeScript type Email = /some-long-email-regex/;
2. コアライブラリの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`
}

@Igmatクール。 あなたの提案はTypeScriptにとってより自然に感じられ、コンパイラへの変更が少なくて済みます。それはおそらく良いことです。 私の提案の唯一の利点は、正規表現リテラルが文字列および数値リテラルと同じように感じられることでした。これは、一部の人にとって混乱を招く可能性があります。

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

しかし、私はあなたの提案の単純さが一つの欠点を上回っていると思います。

編集： ValidatedStringType<R>の長さはあまり好きではありません。 検証済みの文字列パターンを呼び出すことにした場合、結局PatternOf<R>使用できます。 あなたのタイプがタイプするのにもっと時間がかかると言っているのではありません。ほとんどの人は最初の3文字をタイプしてタブを押すだけです。 コードのspagetificationへの影響が大きくなります。

@Igmatあなたのソリューションは開発の観点からは優れていますが、読みやすさが増すにつれて、

@Akxe開発者が1つの非常に特殊なユースケースしかない別のキーワードを追加したいとは思わない。

@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と競合しています。 これで、型をジェネリック引数としてのみ渡すことができ、任意の式を渡すことはできません。 提案された構文は非常に混乱します。

ジェネリック型は、型を取り、型を返す関数のように考えてください。 次の2つのコードは、意味と構文の両方で非常に近いものです。

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

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

新しい構文は、JavaScriptの正規表現をlet all = String(.*)と書くことを提案するようなものです。これは、関数呼び出し構文の醜い乱用になります。 したがって、あなたの提案はあまり意味がないと思います。

@ m93a私の提案は、JavaScriptではなく、型の注釈に関するものでした。

頭のてっぺんからですか：

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

@ amir-arad、申し訳ありませんが、あなたの提案にこれ以上価値のある詳細を追加することはできませんが、 stringは非常に基本的なプリミティブであるため、一見するとTSコンパイラ全体に非常に重要な変更が加えられたように見えます。

明らかな問題は見当たりませんが、そのような提案はもっと詳細で、多くの既存のシナリオに加えて、その目的の適切な正当化をカバーする必要があると思います。
あなたの提案は1つの型を追加し、1つのプリミティブ型を変更しますが、私の提案は1つの型のみを追加します。

残念ながら、私はそのような機能の提案を作成するために多くの時間を割く準備ができていません（また、TSのすべての提案が大幅な遅延なしに実装されているわけではないことに気付くかもしれません）が、これに取り組むなら、私は必要に応じて、私のフィードバックを喜んで提供します。

これらの正規表現が実際の正規表現（正規ではないPerlのような正規表現ではない）である場合、それらを決定性FSMに変換し、それらに直積集合を使用してすべての接続詞と論理和を取得できます。 正規表現はブール演算で閉じられます。

また、文字列リテラル型がアトミックではなく、コンパイル時の文字リストとして表されている場合は、ライブラリにすべての演算子を実装できます。 それはパフォーマンスを少し悪化させるだけです。

編集：間違いを修正します。

ミスリルが実際にこれらを使用できることに

• 私たちのライフサイクルフック、 oninit 、 oncreate 、 onbeforeupdate 、 onupdate 、 onbeforeremove 、およびonremoveには、独自のフックがあります特別なプロトタイプ。
• DOM vnodeのイベントハンドラーは、文字通りonで始まるものであり、イベントリスナー関数とイベントリスナーオブジェクト（ handleEventメソッドを使用）の両方をサポートし、 addEventListenerとremoveEventListener 。
• 必要に応じて、キーと参照をサポートします。
• それ以外はすべて、バッキングDOMノード自体に存在するかどうかに応じて、属性またはプロパティとして扱われます。

したがって、正規表現で検証された文字列型+型の否定を使用すると、DOMvnodeに対して次のことができます。

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}` -これは機能的に正規表現/^value/と同等ですが、 "value" 、 "valuea" 、および"valueakjsfbf aflksfief fskdf d"はすべて割り当て可能です。
• `foo${string}bar` -これは機能的には正規表現/^foo.*bar$/と同等ですが、正規化が少し簡単です。
• もちろん、複数の補間が存在する可能性があります。 `foo${string}bar${string}baz`は、有効なテンプレートリテラルタイプです。
• 補間はstring拡張する必要があり、再帰的であって
• テンプレートリテラルタイプAは、 A割り当て可能な文字列のセットが、 B割り当て可能な文字列のセットのサブセットである場合にのみ、テンプレートリテラルタイプB割り当てることができます。 B 。

上記に加えて、特別なstarof T型が存在し、 Tは1文字の文字列リテラル型のみで構成されている必要があります。 stringは、 starof (...)型エイリアスとして存在します。ここで、 ...は、U +0000からU + FFFFまでのすべての単一UCS-2文字列リテラルの和集合です（単独を含む）。代理。 これにより、ESの基数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 $ {inferT}。$ {infer U} ? [T, U] : neverは["foo", "bar.baz"]ではなく["foo.bar", "baz"] ["foo", "bar.baz"]返します。

技術的な観点から、これは生の正規表現よりもはるかに実装可能です。 JSの正規表現でも定期的ではありません-彼らは状況依存型のバック参照となり、彼らは同様の形で多くの複雑さ正規言語を、それぞれ1つを基礎となる理論と非常に密接に一致します（ただし、そのサブセットのみをサポートします）。

• 空の言語： ""
• ユニオン： "a" | "b"
• 連結： `${a}${b}`
• クリーネ閉包（部分的）： starof T （ Tは、単一の文字と共用体のみを含めることができます。）

これにより、文字列のサブタイプがサブグラフ同型問題の最悪のシナリオのサブセットをチェックするようになる可能性がありますが、ここにはいくつかの大きな償還要因があります。

1. はるかに一般的なケースは、小さな有限の文字列の結合です。これは、木でモデル化できるものです。 これは比較的明白です。 （上記のマッチングアルゴリズムが複雑になるため、ロープとして結合することはお勧めしませんが、単一文字の和集合などを単一の分割+結合に正規化することはまったく問題ありません。）

2. 統合タイプ全体を有向グラフとしてモデル化できます。ここで、

   1. このような文字のスター付きユニオンは、親ノードがサブグラフの各文字と各子ノードの両方にエッジを持ち、各文字が他のすべての文字とサブグラフのすべての子ノードの両方にエッジを持っているサブグラフです。
   2. グラフの残りの部分は、他のすべての可能性を表す有向ツリーのような構造を保持しています。

   私が簡単に行ったこのMath.SEチャット（ほぼここから開始）によると、この結果のグラフには、有界の属（つまり、他のエッジを超えるジャンプの数が有限*）と、 starofがないことの両方があることがわかりました型の平等がそれを多項式時間の問題に還元することを意味強く思います。 （上記のリンク先のウィキペディアの記事には、「アルゴリズム」にいくつかの例があり、特別な大文字と小文字が適用される可能性のあるセクションを参照しています。）




3. これらのキーはどれも大きくなる可能性が低いため、ここでの実際の実行時コストのほとんどは、実際には他の方法で償却されます。 小さなキーに対して高速である限り、それで十分です。




4. 比較されるすべてのサブグラフは、少なくとも1つのノード（ルートノード）を共有します。 （これは文字列の始まりを表します。）したがって、これはそれ自体で問題スペースを劇的に減らし、多項式時間チェックを保証します。

もちろん、そのようなタイプの交差は重要ですが、上記の制限のために、同様の償還要因が存在するように感じます。 特に、最後の制限により、明らかに多項式時間で実行できます。

*数学的には、属はプログラマーにとって少し直感に反して定義されます（ジャンプなしでグラフを描画するためにサーフェスに突き刺す必要のある最小の穴の数）が、制限された属（限られた数の穴）は限られた数のジャンプを意味します。

この具体的な提案を使用して、このコメントからの私の例がどのように翻訳されるかを次に示します。

// 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. タイプスクリプトリポジトリの所有者はこのアイデアを受け入れているようで、正しい提案を待っています。 ＃3136を参照

F＃にはオープンソースの正規表現タイププロバイダーがあります。

タイププロバイダーに関するいくつかの情報： https ：

タイププロバイダーが実装され、正規表現タイププロバイダーがオープンソースライブラリとして実装されると、次のように使用することが想像できます。

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は構造的に型付けされており、名目上型付けされていません。文字列リテラルの操作については、その構造的な精神を維持したいと思います。 そのようなタイプのプロバイダは、公称作成しますstringサブタイプRegexProvider</^foo$/>と同等に扱われることはない"foo"が、それの名目上のサブタイプを。 さらに、 RegexProvider</^foo$/>とRegexProvider</^fo{2}$/>は、2つの異なるタイプとして扱われますが、それは私が好きではないことです。 代わりに、私の提案は、文字列をコアに直接統合し、形式言語認識の理論から直接情報を得て、自然に収まるようにします。
• 私の場合、文字列を連結するだけでなく、 Key extends `on${infer K}` ? K : neverまたはKey extends `${Prefix}${infer Rest}` ? Rest : never介して文字列の一部を抽出することもできます。 タイププロバイダーはこの機能を提供しておらず、そのような機能が追加された場合にどのようにすべきか明確な方法はありません。
• 概念レベルでは、私のものはかなり単純です。文字列連結型を追加し、条件付き型のRHSの場合は、その逆を抽出する機能を追加することをお勧めします。 また、正規表現/.*/の代わりに、 string自体と統合することを提案します。 APIを変更する必要はなく、コードベースの残りの部分からほとんど切り離されている2つの理論的に複雑な部分を除けば、テンプレートリテラル型が別の型に割り当て可能かどうかを計算し、文字列からスライスを抽出することは、単純ではないにしても同様です。 、 実装する。

ところで、私の提案はまだその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} $ />は、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"はあなたのタイプに割り当て可能ですか？ （もしそうなら、それは実装を複雑にし、チェッカーをかなり遅くします。）

手元の議論に半関連して、タイプが固定長（電話番号など）でない場合はどうなりますか？ 最近これを使用したいと思った状況の1つは、 thread_{number}形式の部屋名を保存する場合です。

このような値に一致する正規表現はthread_[1-9]\d*です。 提案されているものでは、そのようなフォーマットに一致させることは実行可能ではない（または不可能でさえある）ように思われます。 この状況では、値の数値部分はゼロより大きい任意の長さになる可能性があります。

@jhpratt少し変更するだけでよいので、それに対応するためにstarof ("0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9") ↔ /^\d*$/の形式で提案を修正しました。 stringが/^[\u0000-\uFFFF]*$/と同じように最適化されるので、先に進んでそれを一般化することにしました。

計算の複雑さの懸念から、任意の非再帰的和集合を受け入れるように、 starofそれ以上拡張したくありません。2つの任意の正規表現*が等価であるかどうかの検証は、多項式空間または多項式時間で実行できます（両方を最小限のDFAに変換して比較します（通常の方法ですが、実際には非常に遅いです）が、両方の方法は実際にはa{2} ）、基本的に実行不可能です（指数関数的な複雑さ） 。 これは同等性のためだけであり、正規表現が文字列のサブセットと一致するかどうかのチェックは、割り当て可能性のチェックに必要な、別の正規表現が一致する文字列のサブセットと一致するかどうかを確認することは明らかにさらに複雑になります。

*数学的な意味での正規表現： () 、 (ab) 、 (a|b) 、および(a*)単一文字のみを含めます。ここで、 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は次のような検証関数のみを受け入れることができました。

• 「ベース」タイプである必要がある/想定される単一の引数を持つ
• バリデーター関数で定義されている参照変数のみ
• 値を返します（検証プロセスでブール値に強制されます）

上記の条件は、typescriptコンパイラにとって簡単に確認できるように見えます。これらの条件が想定されると、実装の複雑さの多くは解消されます。

さらに、必要に応じて、初期スコープを管理可能なサイズに制限します。

• 検証関数は、ネイティブタイプ（文字列、数値）のサブセットにのみ追加できます

この最後の制限はそれほど必要ではないと思いますが、それが必要かどうかについて疑問がある場合は、上記の制限のある解決策であるため、それについて議論するのに多くの時間を費やす価値はないと思います。それでも、実際のユースケースの膨大な範囲を解決できます。 さらに、上記の制限を後で緩和すると、基本的な構文を変更する必要がなく、コンパイラによる言語サポートの幅が広がるだけの単純で自然な拡張になるため、上記の制限の欠点はほとんどありません。

@mewaligつまり、ランタイム関数のように見えるものは、実際にはランタイムではなく、コンパイル時（および署名可能性をチェックするたび）に実行されます。 これらの関数は、ランタイム（変数、関数）

さらに、一般的に、コンパイラにスローしたもの、特に最適化が不十分な関数や完全に悪意のあるwhile(true){}を実行させたくありません。 メタプログラミングが必要な場合は、スマートに設計する必要があります。 実行時コードをコンパイル時にランダムに実行できるようにすることは、それを実行するための「PHPの方法」です。

最後に、提案する構文は通常のパターンを切り替えます

let runtime: types = runtime;

（つまり、コロンの後のタイプ）裏返し、事実上

type types = types: runtime;

それは恐ろしいです。 だからあなたの提案に感謝します、しかしそれは間違いなく悪い考えです。

これらの関数は、ランタイム（変数、関数）

コンパイラがある場合はもちろん、彼らは、ECMAScriptのは、それが利用可能なランタイムができ（ tscところで、ありません！）。 コンパイル時のセマンティクス、たとえばfetch()と実行時のセマンティクスには明らかにあいまいな問題がありますが、それが反復の目的です。

実行時コードをコンパイル時にランダムに実行できるようにすることは、それを実行するための「PHPの方法」です。

これは、 C ++のconstexpr関数と非常によく似ています。 解決策は、 constexprはconstexprしか使用できないが、すべてがconstexpr使用できるということです。 次に、コンパイル時のファイルシステム用にconstexpr同等のバージョンのファイルシステムを作成できます。これは非常に強力です。

構文も私には大体うまく見えます。LHSはタイプですが、もちろんRHSもある種のタイプです。 私の問題は、「ベース」タイプを超えてタイプを構成する方法に関するものですが、それもすべて解決可能です。

だからあなたの提案に感謝します、しかしそれは間違いなく悪い考えです。

それは悪い考えになってしまうかもしれませんが、今のところ私は、typescriptの目標から大きく外れる必要があると思われる非常に特定されていない考えを見ているだけです。 それに似た良いアイデアがないかもしれないという意味ではありません！

この機能に関する議論は今のところ止まっているようです（ 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

ただし、関数パラメーターで正規表現型を使用する場合は、山括弧構文を使用して、一致した文字列を推測することを意味できます。 例えば

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 / lodashget関数

このコードが機能するように、タイプセーフな「文字列パス」ゲッターを実装できます。

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

しかし、おそらくそれは解決するために必要となる、これを我々は可能性の固定最大数のために多くの過負荷を回避したい場合はgetの「深さ"。

1. マップされたタイプで抽出されたパラメーターを使用します。

たとえば、 https：//github.com/Microsoft/TypeScript/issues/12754のようなことができるとしたら{ [ StripAsyncSuffix<P> for P in K ] : T[P] }ような構文、誰かがすでにそのようなものを提案しています）

おそらく他のユースケースもあるでしょう。 しかし、私はほとんどがこれらの2つのタイプに当てはまると思います（1.提供された文字列リテラルに基づいて適切なタイプを見つけ出す、2。入力タイプのプロパティ名を新しい定義されたタイプの新しいプロパティ名に変換する）

これは私たちができることです。

私は現在、URLを検証できるようにするためにカスタムlintルールを構築しています-ただし、オプションのparamsを定義できれば、これははるかに簡単です-IDを検証できるようにするために正規表現が必要です

一般に、これにより、コードベース全体で小道具の有効性を主張するためのより多くの力が得られます。

タイププロバイダー、テンプレート文字列リテラル、またはその他の提案に動きはありますか？ これはとても素晴らしいツールになるでしょう。

これに対する私の回避策は、現在、このようなマーカーインターフェイスを使用することです。

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ここに提案があり、2016年後半に別の提案が作成されたので、このラベルを更新できますか？

上記の提案を確認し、いくつかの質問とコメントがあります。

これまでの提案の問題点

エミットを作成するタイプ

私たちは型システムを完全に消去し続けることを約束しているので、発行されたコードを生成するために型エイリアスを必要とする提案は範囲外です。 このスレッドで、おそらく明らかではない方法でこれが発生したいくつかの例を強調します。

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");

交差点の禁止

実際には、一般的なタイプと正規表現で検証されたタイプは実際には異なるため、correcltyがそれらの和集合と共通部分をどのように処理するかについてのルールが必要です。

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

TypeScriptは交差点のインスタンス化でエラーが発生しないため、これは最終的な設計の一部にはなりません。

人間工学

全体として、私たちの最も重要なポイントは、同じ正規表現を2回（値空間で1回、型空間で1回）

タイプemitに関する上記の懸念を考えると、最も現実的な解決策は、値空間に式を記述することです。

// 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

もちろん、正規表現を型空間に書き込むこともできますが、実行時の検証は利用できず、文字以外の使用には再テストまたはアサーションが必要になります。

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);
    }
}

ユースケースの収集と明確化

新しい種類のタイプについては、理想的には次のようないくつかの例を見てみたいと思います。

• 解決されている問題には、より良い代替手段はありません（まだ言語に含まれていないもっともらしい代替案を含む）
• この問題は、実際のコードベースで意味のある頻度で発生します
• 提案された解決策はその問題をうまく解決し

リテラルのコンパイル時検証

このスレッドは、さまざまなユースケースを意味します。 具体的な例はもっとまれです。 厄介なことに、これらの例の多くは完全ではないようです。有効な入力を拒否する正規表現を使用しています。

• フォントの色-16進数の色を受け入れるものはすべて、「白」や「スカイブルー」なども受け入れます。 これにより、 rgb(255, 0, 0)構文も誤って拒否されます。
• SSN、郵便番号など-OKですが、コードにリテラルのSSNまたは郵便番号が含まれているのはなぜですか？ これは実際に記名的型付けの必要性ですか？ 正規表現で正確に記述できない文字列のサブクラスがある場合はどうなりますか？ 「競合する提案」を参照してください
  
  
  
  • 整数- "3e5"誤って拒否します
  
  
  • 電子メール-これは通常、悪い考えと見なされます。 繰り返しになりますが、コードに電子メールアドレス文字列リテラル
  
  
  • CSSボーダーの仕様-スタンドアロンライブラリは、それ自体がサポートするDSLを記述するための正確な正規表現を提供できると信じていました
  
  
  • テストを書く-あなたのテストコードは、おそらく無効な入力の多くを提供しなければならないので、これはほとんど対位法ですが、ハードコードの入力は、いくつかの意味を作る場所です
  
  
  • 日付形式-どのように/なぜ？ Dateは、このためのコンストラクターがあります。 入力がランタイムの外部からのものである場合は、名目型が必要です
  
  
  • URI - fetchがhostをhttp(s?):と一緒にいないことを指定すると想像できます
  
  

TODO：RegExpタイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

一つの懸念は「precisionitis」である-誰かが親切ので、すべての非リテラルの呼び出しを壊し、DefinitelyTypedまで表示され、ライブラリ内のすべての関数への正規表現の種類を追加したときに何が起こりますか？ さらに悪いことに、定義ファイルの作成者は、検証RegExpの「正しいスペル」が何であるかをそのコンシューマーに正確に同意する必要があります。
これにより、すべてのライブラリにURLとしての資格、ホスト名としての資格、電子メールとしての資格などの独自のバージョンがあり、2つのライブラリを接続しているにたどり着くようです。コンパイラを満足させるには、型アサーションを挿入するか、正規表現をコピーする必要があります。

ランタイムチェックの実施

以前の人間工学セクションのfnように、関数の引数が以前の正規表現によって検証されていることを確認したいチェックについての議論がいくつかありました。 テストが必要な正規表現がよく知られている場合、これは簡単で価値があるように思われます。 ただし、これは大きな「if」です。私の記憶では、検証正規表現を提供する単一のライブラリを思い出せません。 検証機能を提供する場合がありますが、これは、提供される機能が正規表現タイプではなく、名義タイプまたはタグ付きタイプであることを意味します。

この評価に対する反証は歓迎されます。

プロパティキー/正規表現文字列インデクサー

一部のライブラリは、プロパティ名に従ってオブジェクトを処理します。 たとえば、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機能のほとんどはかなり難解であるか、グループマッチングに関連しており、ここでのほとんどのユースケースと一致していないようです。

パフォーマンス

正規表現は無制限の量の作業を実行でき、大きな文字列との照合は任意の量の作業を実行できます。 ユーザーはすでに他の方法で自分自身をDOSすることができ、悪意を持って非効率的なRegExpを作成する可能性はほとんどありません。

サブタイピング（ /\d*/ -> /.*/ ？）、和集合、共通部分、および居住不能

理論的には、 /\d+/は/.+/既知のサブタイプです。 おそらく、あるRegExpが別のRegExpの純粋なサブセットと一致するかどうかを判断するアルゴリズムが存在しますが（特定の制約の下で）、明らかに式を解析する必要があります。 実際には、RegExpesが一致するものに基づいて暗黙のサブタイプ関係を形成しなくても100％問題ありません。 これはおそらくさらに望ましいです。

割り当て可能性の関係が正しく定義されている限り、和集合と交差の操作は「箱から出して」機能します。

TypeScriptでは、2つのプリミティブ型が交差点で「衝突」すると、それらはneverに減少します。 2つのRegExpが交差する場合、2つの式の交差に一致する新しいRegExpを生成しようとするのではなく、 /a/ & /b/として保持します。 neverへの削減はありません。文字列が両側を満たすことができないことを証明するアルゴリズムが必要です（これは、前述のre：サブタイプと並行する問題です）。

次のステップ

要約すると、次のステップは次のとおりです。

• 正規表現名のプロパティキー、別名正規表現文字列インデクサーについて別の問題を提出する
• 文字列リテラルのコンパイル時検証のための具体的でもっともらしいユースケースを取得する
  
  
  
  • 例：DefinitelyTypedまたは他のライブラリでこれから非常に恩恵を受ける関数を特定します
  
  
• 名目/タグ付き/ブランドタイプが、非リテラル検証のためのより柔軟で広く適用可能なソリューションであるかどうかを理解します
• 検証正規表現をすでに提供しているライブラリを特定する

ユースケース：Hyperscript（https://github.com/hyperhype/hyperscript）のような関数
ハイパースクリプト関数は通常、 h('div#some-id')ように呼び出されます
正規表現のようなパターンマッチャーを使用すると、 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>;
}

ユースケース：関数のようなハイパースクリプト（hyperhype / hyperscript）

その正規表現はどのように見えますか、またはそれはどのような検証を提供しますか？ これは正規表現ベースの関数のオーバーロード用ですか？

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タイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

私のユースケースは、CCXTライブラリのこのコメントで説明したもので、 TickerSymbolを表す文字列があります。 正規表現パターンがチェックされているかどうかはあまり気にしませんが、 stringサブタイプとして扱われるようにしたいので、より厳密な割り当てやパラメータータイプのチェックなどが行われます。関数型プログラミングをしているときに非常に便利です。コンパイル時にTickerSymbols、Currencies、Assetsなどを簡単に追跡できますが、実行時には通常の文字列です。

@omidkradこれは、正規表現で検証された型ではなく、名義型が必要なようです。

@ m93a私の場合、

CSSセレクターも検証できます

CSSセレクターは正規表現では検証できません

さて、正規表現でそれらをつなぎ合わせることができれば、CSS正規表現をコピーできます...そうですか？

（ドラフト）CSS型付きオブジェクトモデル

https://drafts.c​​ss-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};

ところで、このシームレスな統合と複雑さの回避が、文字通りの正規表現よりも私の提案を好む理由です。

ただし、純粋な正規表現タイプでこれを行う方法はわかりません。 私はそれを指摘したいと思います。

TODO：RegExpタイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

曲がったものは、期待される応答タイプを説明する文字列として与えられたものに基づいて、異なる戻りタイプを持っています。

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

メソッドや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 + liErQgwCgkg2ugMWER0EY0QA7tFyFShogZsp​​DAotjyABbAYBgVBmAD0Eqk0XYYApADoSOx + Q0 + GCBVsgA

申し訳ありませんが、私の問題は、ベースURLを検出するために文字列の先頭でhttp(s):を照合することに沿っていたと思います。

ベントの署名は、

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:の存在をチェックするため、bentの動作と「不適切に」一致します。

正規表現タイプがある場合は、BaseUrlをtype BaseUrl = /^https?:/として定義できます。これにより、HTTPメソッドまたは応答エンコーディングではない文字列が適切に検証され、 string吸収されないことが理想的です。タイプ。

まさに、私は同じです。

-
Prokop Simek

2019年10月20日03：23：30、Michael Mitchell（[email protected]）
書きました：

ああ、申し訳ありませんが、私の問題はもっと
一致するhttp（s）：ベースURLを検出するための文字列の先頭。

ベントの署名は、

タイプHttpMethods = 'GET' | 「パッチ」| ... type StatusCode = number; type BaseUrl = string; //これは、文字列がhttp（s）：type Headers = {[x：string]：any;と一致するかどうかを理想的に確認する必要がある場所です。 };
タイプOptions = HttpMethods | StatusCode | BaseUrl | ヘッダー;
関数bent（... args：Options []）：RequestFunction関数bent（... 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=ABJ3U4JNK3V5MV4DJH73ZU3QPOXJFA5CNFSM4BZLAVSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
または購読を解除する
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');

IOW正規表現で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に割り当てることはできません。

@RyanCavanaughMithril用にこれらを正しく入力する必要があります。

// <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）

しかし、（あまりにも多くの）人々がすべてを尽くし、ライブラリが相互に互換性を持たないようにするクレイジーな方法ですべての型演算子を使用しているのを見ることはありません。 私は、ライブラリの作者は十分に頭がおかしい傾向があると思うのが好きです...そうですか？

文字列パターン型/正規表現で検証された文字列型を望んでいたことはめったにありませんが、コードベースの型の安全性を高めるのに間違いなく役立ちました。

使用事例

頭のてっぺんから、最近の1つの例を考えることができます。 （もっとたくさんありますが、私は忘れられている存在です）

ストライプの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だけです。 値は2つだけです。
開発者は、 trueとfalseリテラルを持っていることに満足しています。これは、他に求めるものがあまりないためです。

number型は有限ですが、値が非常に多いため、無限と見なした方がよいでしょう。
指定できるリテラルにも穴があります。

これが、範囲番号タイプとNaN, Infinity, -Infinity問題が非常に人気があり、ポップアップし続ける理由です。 無限のセットから小さな有限の値のセットを指定できることは十分ではありません。

範囲を指定することは、無限集合の大きな有限/無限サブセットを指定する必要があるときに誰かに思い浮かぶ最も一般的/自然なアイデアの1つです。

bigintタイプは基本的に無限であり、メモリによってのみ制限されます。

また、範囲番号タイプの問題の人気にも貢献しています。

stringタイプは基本的に無限であり、メモリによってのみ制限されます。

そしてこれが、この文字列パターン型/正規表現で検証された文字列型の問題が非常に人気がある理由です。

正規表現を指定することは、無限集合の大きな有限/無限サブセットを指定する必要があるときに誰かに思い浮かぶ最も一般的/自然なアイデアの1つです。

symbolタイプ...それも無限です。 そしてまた、ほとんど無制限です。

しかし、 symbolタイプの要素はすべて、ほとんどすべての点で互いにほとんど関係がありません。 そして、「 symbol大きな有限/無限サブセットを指定する方法はありますか？」という質問をする人は誰もいません。

ほとんどの人にとって、その質問は意味がありません。 これを行う意味のある方法はありません（右？）

ただし、プリミティブのサブセットを宣言できるだけではあまり役に立ちません。 私たちも必要です、

• 適切なタイプのリテラルは、それ以上の作業なしで割り当て可能でなければなりません

ありがたいことに、TSはこれを可能にするのに十分正気です。

falseを(arg : false) => voidに渡すことができないと想像してみてください！

• 組み込みの絞り込み方法

  現時点では、これらのリテラルには、組み込みの絞り込み方法として==と===があります。

  リテラルごとに新しいタイプガードを作成する必要があると想像してみてください。

名義/構造タグ/値オブジェクトタイプの問題は、基本的に上記の2つの基準を満たさないことです。 それらはプリミティブ型をオブジェクト型ではない不格好な型に変えますが、とにかくオブジェクト型のように扱われなければなりません。

人間工学

さて、ここでは、文字列パターン、公称タグ、構造タグのタイプについて詳しく説明します。

これらの引数は、 https：//github.com/microsoft/TypeScript/issues/15480にも適用されます。

ライブラリ間の互換性

記名的型は、ライブラリ間の互換性で
これunique symbol 、2つのライブラリで
それは単に行うことはできません。
ボイラープレートタイプのガード、または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)を使用できるからです。 trust-me-operator（ as ）を使用する必要はありません。

ただし、アサーションガードにはボイラープレートが必要です。

型がライブラリ間の互換性を必要としない場合は、文字列パターン型を使用するのが最適であり、人間工学的でもあります。

ライブラリ間の互換性が必要な場合でも、文字列パターンタイプは構造タグタイプよりも優れています。 聞いてください。

モデル化されているドメインが十分に理解されている場合、複数の孤立したライブラリ作成者が同じ正規表現を作成する可能性が非常に高くなります。 構造タグタイプを使用すると、タグに必要なプロパティとタイプを書き込むことができます。

モデル化されているものすべてに文字列形式を指定する標準がある場合、基本的に、すべてのライブラリ作成者が同じ正規表現を作成することが保証されます。 彼らが別の正規表現を書いた場合、彼らは実際には標準に準拠していません。 彼らのライブラリを使いたいですか？ 構造タグタイプを使用すると、それらはすべて何でも書くことができます。 （誰かが誰もが気にする構造タグタイプの標準を開始しない限り？笑）

クロスバージョンの互換性

いつものように、記名型はクロスバージョンの互換性で最悪です。
ああ、あなたはあなたのライブラリにパッチ、またはマイナーバージョンをぶつけましたか？
タイプのデカラレーションはまだ同じですか？
コードはまだ同じですか？
いいえ。 それらは異なるタイプです。

タグタイプが構造的に同じである限り、構造タグタイプは、バージョン間（メジャーバージョンでも）で割り当て可能です。

文字列パターンタイプは、正規表現が同じである限り、バージョン間（メジャーバージョンでも）で割り当て可能です。

または、PSPACE-completeアルゴリズムを実行して、正規表現が同じかどうかを判断することもできますか？ また、正規表現のどのサブクラスが最も一般的であるかを判断し、それらに対して最適化された等価アルゴリズムを実行することもできます...しかし、それは大変な努力のように思えます。

正規表現のサブタイプチェックは便利で、文字列パターンタイプの使用がより人間工学的になることは間違いありません。 範囲サブタイプチェックが数値範囲タイプの提案にどのように役立つかと同じように。

[編集]
このコメントでは、
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だけだとしたら、テストを実行するまでわかりません。

そして、図書館の作者が自分の図書館をドッグフーディングするときにどこでもas使用する場合、下流の消費者はどうでしょうか。 また、どこでもasを使用して、新しいバージョンにアップグレードするときに実行時の問題に遭遇する誘惑に駆られませんか？

文字列パターンタイプを使用すると、どこでもasを使用する理由が少なくなり、ライブラリの作成者とダウンストリームの利用者の両方が変更を簡単に壊すことができます。

（ちょっと長蛇の列ですが、私のポイントのいくつかがうまくいったことを願っています）。

また、私はコンパイル時のテストをたくさん書いいます（そして、TSチームもそうしていることを知っています）。

コンパイル時のテストで、特定のstringリテラルが正規表現チェックに失敗/合格することをテストできれば便利です。 現時点では、これらのコンパイル時テストを行うことはできず、代わりにランタイムテストを使用する必要があります。

また、コンパイル時のテストに失敗/合格した場合、ダウンストリームのコンシューマーはこれらの文字列リテラル（または同様のリテラル）を使用して、正しい動作を期待できると確信しています。

これはすぐに私たちをバベルの塔の状況への道に連れて行ったようです...

これは、実際には、名目/構造タグタイプを使用する場合にさらに当てはまります。 上記の例が示しているように、それらはライブラリ間/バージョン間の互換性のためにひどく機能します...

ただし、正規表現/文字列パターンタイプは、その問題に陥らない可能性が十分にあります（標準化と、

編集

スレッドでよくあることは、これらの正規表現がテストコードの検証に役立つことです。これは、本番シナリオでは、コードがハードコードされたリテラルではなくランタイム提供の文字列に対して実行される場合でも、テスト文字列が「正しい"。 ただし、どちらの方法でも検証関数を記述しているため、これは名目/タグ付き/ブランド文字列の引数のように見えます。テストの利点は、それらが徹底的に実行されることを知っていることです（したがって、テスト入力のエラーは開発サイクルの早い段階でフラグを立てます）。

ああ...これを書く前にまずすべてを読むべきだった...

とにかく、文字列パターンタイプが役立ついくつかの例があります。

HTTPルート宣言ライブラリ

このライブラリを使用すると、HTTPルート宣言オブジェクトを作成できます。 この宣言は、クライアントとサーバーの両方で使用されます。

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

これらは.append()の制約です。

• 文字列リテラルのみ（現時点ではこれを強制することはできませんが、非リテラルを使用すると、ルート宣言ビルダーがガベージになります）
• スラッシュを先頭から始める必要があります（ / ）
• 末尾のスラッシュで終了してはなりません（ / ）
• conlon文字（ : ）を含めることはできません。 パラメータ用に予約されています
• 2つ以上のスラッシュを連続して含めることはできません（ // ）

現在、エラーをスローするこれらの実行時チェックしかありません。 ダウンストリームのコンシューマーは、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コンストラクタ

おかしなことに、 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パスで?を使用することはめったにありません。

私はあなたがこのユースケースをすでに知って

このスレッドは、さまざまなユースケースを意味します。 具体的な例はもっとまれです。 厄介なことに、これらの例の多くは完全ではないようです。有効な入力を拒否する正規表現を使用しています。

したがって、確かに、提案された正規表現の多くは「完全」ではありません。
しかし、彼らが有効な入力を拒否しない限り、それは大丈夫ですよね？

無効な入力を許可しても大丈夫ですよね？
実行時に「実際の」パーサーで完全な検証を処理できるためです。
また、コンパイル時のチェックにより、ダウンストリームユーザーに共通する多くの問題を排除し、生産性を向上させることができます。

有効な入力を拒否する例は、有効な入力を拒否せずに無効な入力を許可するように、簡単に変更できる必要があります。

文字列パターンのタイプと共通部分

とにかく、文字列パターンタイプの交差タイプは非常に便利です！

私の.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とほとんど同じであり、ランタイムチェックを優先して多くの型安全性を排除し、消費する開発者に不便をもたらします。

言及されたいくつかのユースケースでは、正規表現の小さなサブセットのみが必要になります。たとえば、プレフィックスの一致です。

これは、可変個引数の種類＃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;

言及されたいくつかのユースケースでは、正規表現の小さなサブセットのみが必要になります。たとえば、プレフィックスの一致です。

私はまだ私の提案を支持し星のない言語の非常に小さなスーパーセットであり、サブセット化と同等性を合理的に効率的にチェックできます。 そしてこれまでのところ、TSチームが抱える最大の懸念である、任意の正規表現のパフォーマンスの側面に対処する他の提案は見たことがありません。

スターフリー言語の問題は、その名前が示すように、スターを使用できないことです。これにより、URLなどの検証が困難になります。 その上、ほとんどの人はおそらく星を欲しがり、それらをエミュレートするために任意の数の繰り返しシーケンスを使用するだけであり、サブセットをチェックするのが難しくなります。

そして、ほとんどの通常のDFA表現可能な正規表現のパフォーマンスはそれほど悪くはなく、サブ/スーパーセットについてこれらをチェックすることが可能です。

ただし、 *を取得することはできます。

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

@TijmenW私の提案をもう少し詳しく読んでください-そこにはいくつかの隠された理論的根拠と、それを実際に実用的にするいくつかの小さな機能があります。 星のない文法を指定することに直接限定されるのではなく、小さなスーパーセットが拡張されて、私のセミアドバンスのユースケースに実用的に役立つようになりました。 特に、あなたが行うことができますstarof ('a' | 'b' | ...)個々の文字のために、あなたが使用することができますstringと同等としてstarof UnionOfAllCodePoints （理論的には、それはもはや原始作っていない効果で）。

また、正規言語が他の正規言語が一致するもののサブセットと一致するかどうかをチェックすることはNP完全であり、一般的なサブグラフ同型問題と同等です。 これが、標準の正規言語だけを実行できない理由であり、理論的な計算の複雑さを抑えるために、 starofを可能な限り制限しようとした理由です。

TODO：RegExpタイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

これはまったく新しいライブラリなので、一粒の塩でこれを取りますが、 https：//github.com/ostrowr/ts-json-validatorのようなライブラリは、正規表現タイプのようなものではるかに便利になります。

ライブラリの目的は、TypescriptタイプとJSONスキーマのペア<T, s>ように生成することです。

1. sが検証できるすべてのタイプは、 T割り当てることができます。
2. sに対して実行すると、 T割り当て可能なタイプができるだけ少なくなり、検証に失敗します。

正規表現タイプは、検証されたタイプが少なくとも次のキーワードについてより厳密になることを許可することにより、（2）の厳密さを改善します。

• format
• patternProperties
• propertyNames

TODO：RegExpタイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

すべてのExcelインターフェイスライブラリは、型の検証をA1またはA5:B7として使用できます。

プロパティキー/正規表現文字列インデクサー

一部のライブラリは、プロパティ名に従ってオブジェクトを処理します。 たとえば、Reactでは、名前がaria-始まるすべてのプロップにタイプを適用します。

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

これは事実上直交概念です（Regexプロパティキーを追加せずにRegexタイプを追加でき、その逆も可能です）。

私はこれがここで起こっているすべてに少し直交していることを知っていますが、ウェズリーはあなたが私たちの入力を使うことができると思いました。 これは、さまざまな理由でファブリックで発生し続けます。 コンポーネントライブラリとして、 data- aria-属性と消費者への

何かお手伝いできることがありましたらお知らせください。 😄

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タイプの恩恵を受ける可能性のある実際のライブラリ関数と、使用する実際の式を特定してください。

cronジョブ。 （これが言及されていないことに非常に驚いた）

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

ここに2セントを投入するだけです。HTMLのid属性として使用される小道具を検証したいReactプロジェクトに取り組んでいます。 これは、次のルールを満たす必要があることを意味します。満たさない場合、予期しない動作が発生します。

1. 少なくとも1人のキャラクターがいる
2. スペースがありません

言い換えると：

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

別の例： '<namespace>/<name>[@<version>]'形式で文字列が期待されるsanctuary-type-identifiers

ユースケース： Navigator.registerProtocolHandler()ような文字列型のDOMAPI。

MDNの引用：

セキュリティ上の理由から、 registerProtocolHandler()は登録できるスキームを制限します。

カスタムスキームは、次の条件を満たしている限り登録できます。

• カスタムスキームの名前はweb+始まります
• カスタムスキームの名前には、 web+プレフィックスの後に少なくとも1文字が含まれます
• カスタムスキームの名前には小文字の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理論的には単なるサブセットであり、文字列型を具体的に

言及されたいくつかのユースケースでは、正規表現の小さなサブセットのみが必要になります。たとえば、プレフィックスの一致です。

私はまだ私の提案を支持し星のない言語の非常に小さなスーパーセットであり、サブセット化と同等性を合理的に効率的にチェックできます。 そしてこれまでのところ、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

興味があります：正規表現の包含/包含を決定することは可能ですか？ ウィキペディアに
これはこの機能に影響します（絞り込み）：

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

@nikeee決定可能では、これを現実的にするのに十分ではありません。 二次時間でさえ、このスケールでは一般に遅すぎます。 TSではありませんが、私は同様の問題についていくつかの背景を持っています。

後方参照に直面して、私はそれがまだ決定可能であると思うが、悪くはないにしても指数関数的である可能性が高い。 しかし、ただの知識に基づいた推測です。

これを明確にしてくれてありがとう！

二次時間でさえ、このスケールでは一般に遅すぎます。

だから私はそれが計算上実行可能かどうかも尋ねたので、そうではないと思います。

同じことが平等にも当てはまる場合、それはこの機能のほとんどすべてのプロパティが実行不可能であることを意味しませんか？ 私が間違っている場合は訂正してください。ただし、残っているのはメンバーシップだけのようです。 これだけでは役に立たないと思います。

@nikeeeこのパターンは、比較されるすべてのタイプの文字通りすべてのプロパティに対してチェックされることを覚えておく価値があります。 また、正規表現プロパティを持つ型の場合、正規表現が別の正規表現が一致するもののサブセットと一致するかどうかを計算する必要があります。これは、それ自体がかなり複雑な獣です。

それは不可能ではなく、ただ難しいだけです。それを実現可能にしたいのであれば、制限する必要があります。 （1つには、JS正規表現は機能しません。十分に拡張可能であるだけでなく、柔軟性もあります。）

編集：私はこれを繰り返したいと思います：明確にするために、私はTSチームに所属していません。 私はCSアルゴリズムの設計にまともなバックグラウンドを持っています。

うーん、多分あなたは「通常の」正規表現の「限定された」サブセットしかサポートできないでしょう。 ユースケースを考えると、これまでのところ正規表現は非常に単純でした…（色、電話番号など）

サブセットのみをサポートする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}`

（これは、実装が共用体型を使用することを前提としています。別の/より複雑な実装で機能する可能性があります）

Dislaimer：私はTSチームの一員ではなく、TSに取り組んでいません。 ちょうど私の2c。

@rozzzly @nikeeeそれは多かれ少なかれ私の提案の本質ですが、いくつかの小さな機能が欠けています。 私は正規表現（正式な言語の概念）の大規模なサブセットに基づいており、正規表現などの意味での正規表現ではないため、正規表現よりもはるかに強力ではありませんが、仕事を遂行するのに十分強力です。

このアプローチの方がユーザーフレンドリーだと思います。 ただし、型の算術演算と同等のようです。

数学によれば、ある型が別の型のサブ型であるかどうかを検証することは、文字列が特定の形式言語に含まれているかどうかをチェックすることと計算上同等です。

特にドメイン検証は、TLD /パブリックサフィックスの有効性もチェックする場合、実際にはかなり複雑なことです。 RFCによるジェネリックドメイン自体は、 /[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)+/ +最大255文字と同じくらい単純ですが、上記の正規表現が示すように完全な正規文法を使用しない限り、これでも入力が非常に複雑です。 @rozzzlyまたは私の提案からの文字列のみを使用して、プログラムで非常に簡単に型を生成できます（読者の演習として残しておきます）が、最終結果はまだかなり複雑です。

@isiahmeadows

それは多かれ少なかれ私の提案の本質ですが、いくつかの小さな機能が欠けています。

このスレッド全体を最後に読んだのは1年以上前のことです。 私は休憩中に通知を見ました。 @ rugkのコメントを読んでください。本質的に同じ_（/非常に類似した）_アイデアについて、かなり詳細な提案を提案しました。

...上記の正規表現が示すように、完全な正規文法を使用しない限り、これでも入力が非常に複雑になります。 @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の間の整数」（メッセージバッファの割り当ての長さを考えてください）でさえ範囲外と見なされる場合、現時点ではこの問題はタイプスクリプトで意味があるとは言えません。

@simonbuchan他に何もないとしても、少なくともプレフィックスとサフィックスのタイプが存在する必要があります。 それ自体が多くのDOMライブラリとフレームワークに必要です。

私はこれが殴打されて死にました、そしていくつかの良い提案がすでに与えられたことを知っています。 しかし、私は、一部の人が少し面白いと思うかもしれないものを追加したかっただけです。

後方参照に直面して、私はそれがまだ決定可能であると思うが、悪くはないにしても指数関数的である可能性が高い。 しかし、ただの知識に基づいた推測です。

逆参照により、正規表現は文脈自由文法のスーパーセットである文脈依存文法を記述できます。 そして、CFGの言語の平等は決定不可能です。 したがって、線形拘束オートマトンと同等のCSGの場合はさらに悪化します。

DFAに変換できるすべての正規表現が正規表現（連結、和集合、星、共通部分、補集合など）で使用されているとすると、正規表現をNFAに変換するとO（n）になり、2の積が得られます。 NFAはO（m * n）であり、受け入れ状態の結果のグラフをトラバースするとO（m * n）になります。 したがって、2つの正規表現の言語の同等性/サブセットをチェックすることもO（m * n）です。

問題は、ここではアルファベットが本当に大きいことです。 教科書は、DFA / NFA /正規表現について話すとき、通常、サイズ1〜5のアルファベットに制限されています。 しかし、JS正規表現を使用すると、アルファベットとしてすべてのUnicodeを使用できます。 確かに、スパース配列やその他の巧妙なハックと等式/サブセットテストの最適化を使用して遷移関数を表す効率的な方法があります...

定期的な割り当ての型チェックをある程度効率的に行うことができると確信しています。

次に、すべての非正規割り当てで、明示的な型アサーションが必要になる場合があります。

私は最近、小さな有限オートマトンプロジェクトに取り組んだので、情報はまだ私の心の中で新鮮です= 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

編集：精度

@rozzzlyからのこのコメントがTS4.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からのこのコメントがTS4.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

_Update_：この機能を少し試した後は、多くのユースケースをカバーしません。 たとえば、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がコンパイル時にこれを実行できることは明らかです。 MyUnionExtendedExoticタイプはSomeArbitraryRegexTypeを満たします。

多分いつか私はより生産的な貢献をするのに十分な知識があるでしょう：/

@rozzzlyからのこのコメントがTS4.1.0で毎晩動作することを確認しました！

わお。 私は正直なところ、少なくともすぐには、これが実装されることを期待していませんでした。

@ chadlavi-判例集

リリースノートには、この制限への言及がいくつかありました。 可能なすべての有効な組み合わせのリストを作成します。この場合、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の六角文字列

より正確には、TS4.1を使用して単純な決定性有限オートマトンを実装しました

つまり、TSにチューリングマシンをすでに実装できます。 したがって、DFAとPDAは、それに比べて「簡単」です。

そして、テンプレート文字列はこれをより使いやすくします。

コアタイプは実際にはシンプルで、30LOC未満に収まります。

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>;

それは難しい部分であるオートマトンを指定しています。

しかし、誰かがTypeScriptDFA™ジェネレーターに正規表現を作成できると確信しています...

また、「長さ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/Cyber​​ZHG/toolbox

もっと意志力があれば、上記のようなものをつかんで、正規表現をTSDFA™に変えるために使用します笑

さて、私はプロトタイプを一緒に投げました、

https://glitch.com/~sassy-valiant-heath

[編集] https://glitch.com/~efficacious-valley-repair <-これにより、より複雑な正規表現の出力が大幅に向上します。

[編集] Glitchは、長期間使用されていない無料のプロジェクトをアーカイブするようです。 だから、ここにファイルを含むgitリポジトリがあります、
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を作成しました。 ここで型システムパーサーについて引き続き議論してください😀