Typescript: सुझाव: रेगेक्स-मान्य स्ट्रिंग प्रकार

हाँ, मैंने इसे निश्चित रूप से टाइप किए हुए, . यहां तक ​​कि हम सेवाओं की परत में ScriptElementKind साथ कुछ इस तरह का उपयोग कर सकते हैं, जहां हम आदर्श रूप से इन्हें विशिष्ट स्ट्रिंग्स की अल्पविराम से अलग सूची के रूप में वर्णित करने में सक्षम होंगे।

मुख्य समस्याएं हैं:

• यह स्पष्ट नहीं है कि इन्हें अच्छी तरह से कैसे लिखा जाए। अगर मुझे "cat" , "dog" , और "fish" अल्पविराम से अलग सूची चाहिए, तो मुझे /dog|cat|fish(,(dog|cat|fish))*/ जैसा कुछ लिखना होगा।
  
  
  
  • यदि मेरे पास "cat" , "dog ", और "fish" लिए स्ट्रिंग शाब्दिक प्रकारों का वर्णन करने वाले प्रकार हैं, तो मैं उन्हें इस रेगेक्स में कैसे एकीकृत करूं?
  
  
  • स्पष्ट रूप से यहाँ दोहराव है, जो अवांछनीय है। शायद पिछली समस्या को ठीक करने से यह आसान हो जाएगा।
  
  
• गैर-मानक एक्सटेंशन इस प्रकार को iffy बनाते हैं।

इस पर विशाल +1, ज़िपकोड, एसएसएन, ओनेट, इसके लिए कई अन्य उपयोग के मामले।

मुझे एक ही समस्या का सामना करना पड़ा, और मैं देखता हूं कि इसे अभी तक लागू नहीं किया गया है, शायद यह कामकाज मददगार होगा:
http://stackoverflow.com/questions/37144672/guid-uuid-type-in-typescript

जैसा कि @mhegazy ने सुझाव दिया कि मैं

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 यह टाइपस्क्रिप्ट को अत्यंत शक्तिशाली बना देगा

सबटाइपिंग _regex-मान्य स्ट्रिंग प्रकार_ के साथ कैसे काम करता है?

let a: RegExType_1
let b: RegExType_2

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

जहां RegExType_1 और RegExType_2 _regex-मान्य स्ट्रिंग प्रकार_ हैं।

संपादित करें: ऐसा लगता है कि यह समस्या बहुपद समय में हल करने योग्य है (देखें नियमित अभिव्यक्तियों के लिए समावेशन समस्या )।

टाइप स्टाइल के साथ भी मदद करेगा: https://github.com/typestyle/typestyle/issues/5 :गुलाब:

JSX में , aria- (और संभावित रूप से data- ) विशेषताओं को जोड़ते देखा है। किसी ने वास्तव में कैच-ऑल के रूप में निश्चित रूप से टाइप किए गए स्ट्रिंग इंडेक्स हस्ताक्षर को जोड़ा। इसके लिए एक नया इंडेक्स सिग्नेचर मददगार होगा।

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

डिजाइन प्रस्ताव

ऐसे कई मामले हैं जब डेवलपर्स को केवल एक स्ट्रिंग के बाद अधिक निर्दिष्ट मूल्य की आवश्यकता होती है, लेकिन उन्हें साधारण स्ट्रिंग अक्षर जैसे सीएसएस रंग, ईमेल, फोन नंबर, ज़िपकोड, स्वैगर एक्सटेंशन इत्यादि के संघ के रूप में गणना नहीं कर सकते हैं। यहां तक ​​​​कि जेसन स्कीमा विनिर्देश भी जो आमतौर पर होता है JSON ऑब्जेक्ट के स्कीमा का वर्णन करने के लिए उपयोग किया जाता है जिसमें पैटर्न और गुण होते हैं जिन्हें TS प्रकार प्रणाली के संदर्भ में regex-validated string type और regex-validated string type of index कहा जा सकता है।

लक्ष्य

डेवलपर्स को टाइप सिस्टम प्रदान करें जो JSON स्कीमा के करीब एक कदम है, जो आमतौर पर उनके द्वारा उपयोग किया जाता है और जरूरत पड़ने पर उन्हें स्ट्रिंग सत्यापन जांच को भूलने से भी रोकता है।

वाक्यात्मक अवलोकन

इस सुविधा के कार्यान्वयन में 4 भाग होते हैं:

रेगेक्स मान्य प्रकार

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

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

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

रेगेक्स-मान्य चर प्रकार

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

और वही, लेकिन अधिक पठनीय

let fontColor: CssColor;

रेगेक्स-मान्य चर प्रकार की अनुक्रमणिका

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

और वही, लेकिन अधिक पठनीय

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

चर प्रकार के लिए गार्ड टाइप करें

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

और वही

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

और बेहतर पठनीयता के लिए परिभाषित प्रकार का उपयोग करना

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

के समान

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

इंडेक्स टाइप के लिए गरार्ड टाइप करें

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

के समान

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

और बेहतर पठनीयता के लिए परिभाषित प्रकार का उपयोग करना

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

के समान

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

सिमेंटिक सिंहावलोकन

कार्य

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

दुर्भाग्य से हम जांच नहीं कर सकते हैं कि एक रेगेक्स इस लेख के कारण कठिन प्रदर्शन प्रभाव के बिना दूसरे का उपप्रकार है। इसलिए इसे प्रतिबंधित किया जाना चाहिए। लेकिन अगले कामकाज हैं:

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

दुर्भाग्य से string चर को regex-validated चर में निर्दिष्ट करना भी प्रतिबंधित होना चाहिए, क्योंकि संकलन समय में कोई गारंटी नहीं है कि यह रेगेक्स से मेल खाएगा।

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

लेकिन हम यहां दिखाए गए अनुसार स्पष्ट कास्ट या टाइप गार्ड का उपयोग करने में सक्षम
सौभाग्य से यह स्ट्रिंग अक्षर के लिए मामला नहीं है, क्योंकि उनका उपयोग करते समय हम यह जांचने में सक्षम होते हैं कि इसका मान रेगेक्स से मेल खाता है।

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

अनुक्रमणिका के लिए संकुचन टाइप करें

अनुक्रमणिका के regex-validated type के साधारण मामलों के लिए अनुक्रमणिका प्रकार के लिए प्रकार 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 प्रकार वास्तव में भिन्न हैं, इसलिए हमें नियमों की आवश्यकता है कि कैसे उनके संघों और चौराहों को सही ढंग से संभालें।

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 प्रकार से संबंधित है जिसमें सामान्य प्रकार के विपरीत प्रभाव पड़ता है, इसलिए यह मान्य टीएस कोड है:

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

जब नीचे कोड नहीं है:

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

लेकिन दूसरा पहले से ही अमान्य था, लेकिन किसी अन्य कारण से (प्रकार की घोषणा गलत थी)।
तो अब हमें उसी प्रकार के नाम के साथ वेरिएबल की घोषणा को प्रतिबंधित करना होगा, जब यह प्रकार regex-validated ।

पी.एस.

उन चीजों को इंगित करने के लिए स्वतंत्र महसूस करें जिन्हें मैंने शायद याद किया है। यदि आप इस प्रस्ताव को पसंद करते हैं, तो मैं इसे कवर करने वाले परीक्षण बनाने और उन्हें पीआर के रूप में जोड़ने का प्रयास कर सकता हूं।

मैं regex-validated प्रकार के चौराहों और यूनियनों के लिए कुछ मामलों को इंगित करना भूल गया हूं, लेकिन मैंने उन्हें नवीनतम परीक्षण मामले में वर्णित किया है। क्या मुझे उस मामूली बदलाव को दर्शाने के लिए Design proposal को अपडेट करना चाहिए?

@Igmat , आपके डिजाइन प्रस्ताव के बारे में प्रश्न: क्या आप उत्सर्जन अवलोकन के बारे में विस्तार से बता सकते हैं? रेगेक्स-मान्य प्रकारों को उत्सर्जित करने की आवश्यकता क्यों होगी? जहां तक ​​​​मैं कह सकता हूं, अन्य प्रकार रनटाइम चेक का समर्थन नहीं करते हैं ... क्या मुझे कुछ याद आ रहा है?

@alexanderbird , हाँ, किसी अन्य प्रकार का उत्सर्जन पर कोई प्रभाव नहीं पड़ता है। सबसे पहले, मैंने सोचा था कि regex-validated भी ऐसा ही करेगा, इसलिए मैंने प्रस्ताव बनाना और प्रस्तावित सिंटैक्स के साथ खेलना शुरू कर दिया है।
पहला दृष्टिकोण इस प्रकार था:

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

और इस:

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

यह ठीक है और इसमें उत्सर्जन परिवर्तन की कोई आवश्यकता नहीं है, क्योंकि "#000" को संकलन समय में चेक किया जा सकता है।
लेकिन हमें इसे उपयोगी बनाने के लिए string से regex-validated प्रकार के संकुचन को भी संभालना होगा। इसलिए मैंने इसके बारे में पिछले दोनों सेटअपों के लिए सोचा है:

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

तो इसका उत्सर्जन पर भी कोई प्रभाव नहीं पड़ता है और ठीक दिखता है, सिवाय इसके कि रेगेक्स बहुत पठनीय नहीं है और इसे सभी जगहों पर कॉपी किया जाना है, ताकि उपयोगकर्ता आसानी से गलती कर सके। लेकिन इस विशेष मामले में यह अभी भी type काम करने के तरीके को बदलने से बेहतर लगता है।
लेकिन तब मुझे एहसास हुआ कि यह सामान:

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

एक बुरा सपना है। और यह चौराहों और यूनियनों के बिना भी है। तो इस तरह की चीजों से बचने के लिए, हमें प्रस्ताव में दिखाए गए अनुसार type उत्सर्जन को थोड़ा बदलना होगा।

@DanielRosenwasser , क्या आप कृपया इस प्रस्ताव के लिए कुछ प्रतिक्रिया प्रदान कर सकते हैं? और यदि संभव हो तो यहां संदर्भित परीक्षणों के लिए भी?
मैं वास्तव में इस सुविधा को लागू करने में मदद करना चाहता हूं, लेकिन इसके लिए बहुत समय चाहिए ( tsc वास्तव में जटिल परियोजना है और मुझे अभी भी यह समझने पर काम करना है कि यह अंदर कैसे काम करता है) और मुझे नहीं पता यह प्रस्ताव लागू करने के लिए तैयार है या आप किसी अन्य भाषा डिजाइन दृष्टि या किसी अन्य कारण से इस तरह से लागू की गई इस सुविधा को अस्वीकार कर देंगे।

अरे @Igmat , मुझे लगता है कि कुछ चीजें हैं जो मुझे शुरू में

शुरू करने के लिए, मुझे अभी भी समझ में नहीं आया कि आपको उत्सर्जित करने के लिए किसी प्रकार के परिवर्तन की आवश्यकता क्यों है, और मुझे नहीं लगता कि प्रकार के आधार पर किसी भी प्रकार का उत्सर्जन स्वीकार्य होगा। यहां हमारे गैर-लक्ष्य देखें।

एक और मुद्दा जो मुझे उठाना चाहिए था वह नियमित अभिव्यक्तियों की समस्या है जो बैकरेफरेंस का उपयोग करते हैं। मेरी समझ (और अनुभव) यह है कि नियमित अभिव्यक्ति में बैकरेफरेंस एक परीक्षण को अपने इनपुट के घातीय समय में चलाने के लिए मजबूर कर सकता है। क्या यह एक कोने का मामला है? शायद, लेकिन ऐसा कुछ है जिसे मैं सामान्य रूप से टालना पसंद करूंगा। यह विशेष रूप से महत्वपूर्ण है क्योंकि संपादक परिदृश्यों में, किसी स्थान पर टाइप-चेक में कम से कम समय लगना चाहिए।

एक और मुद्दा यह है कि हमें या तो उस इंजन पर भरोसा करना होगा जिस पर टाइपस्क्रिप्ट कंपाइलर चलता है, या इन चीजों को निष्पादित करने के लिए एक कस्टम रेगुलर एक्सप्रेशन इंजन का निर्माण करना होगा। उदाहरण के लिए, 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
}

जैसा कि आप देखते हैं, कोड लगभग समान है - यह रेगेक्स का एक सामान्य सरल उपयोग है। लेकिन दूसरा मामला बहुत अधिक अभिव्यंजक है और उपयोगकर्ता को आकस्मिक गलती से रोकेगा, जैसे कि स्ट्रिंग को असाइनमेंट से पहले जांचना भूल जाना जो कि रेगेक्स-मान्य होने के लिए है।
दूसरी बात यह है कि इस प्रकार के संकुचन के बिना हम सामान्य रूप से इंडेक्स में रेगेक्स-मान्य प्रकार का उपयोग करने में सक्षम नहीं होंगे, क्योंकि ज्यादातर मामलों में ऐसे इंडेक्स फ़ील्ड कुछ चर के साथ काम करते हैं जिन्हें रनटाइम में चेक नहीं किया जा सकता है क्योंकि यह शाब्दिक के साथ किया जा सकता है .

@alexanderbird , मैं इस कोड को मान्य बनाने या रनटाइम और संकलन समय दोनों में कुछ छिपे हुए चेक जोड़ने का सुझाव नहीं देता।

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

मेरे प्रस्ताव के कारण इस कोड को त्रुटि फेंकनी है। लेकिन यह:

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

या यह:

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

सही होगा, और उत्सर्जित कोड पर भी इसका कोई प्रभाव नहीं पड़ेगा।

और जैसा कि मैंने पिछली टिप्पणी में दिखाया था, सामान्य उपयोग के मामलों के लिए भी शाब्दिक रूप से पर्याप्त नहीं होगा, क्योंकि हमें अक्सर उपयोगकर्ता इनपुट या अन्य स्रोतों से डंक के साथ काम करना पड़ता है। इस उत्सर्जन प्रभाव को लागू किए बिना, उपयोगकर्ताओं को इस प्रकार के साथ अगले तरीके से काम करना होगा:

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

या चौराहों के लिए:

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

मुझे नहीं लगता कि उपयोगकर्ताओं को कोड डुप्लिकेट करने और स्पष्ट कलाकारों का उपयोग करने के लिए मजबूर करना, जब इसे कंपाइलर द्वारा आसानी से नियंत्रित किया जा सकता है, तो जाने का एक अच्छा तरीका नहीं है। उत्सर्जन प्रभाव वास्तव में बहुत छोटा और अनुमानित है, मुझे यकीन है कि यह उपयोगकर्ताओं को आश्चर्यचकित नहीं करेगा या कुछ फीचर को गलत समझा जाएगा या बग का पता लगाना मुश्किल होगा, जबकि इस सुविधा को बिना उत्सर्जन परिवर्तन के लागू करना निश्चित रूप से होगा।

अंत में मैं यह कहना चाहता हूं कि सरल शब्दों में regex-validated टाइप एक स्कोप्ड वेरिएबल और एक कंपाइलर टाइप दोनों है।

@DanielRosenwasser और @alexanderbird ठीक है, मुझे लगता है कि के लिए एक और विचार है। इस तरह वाक्यविन्यास के बारे में क्या:

const type Email = /email-regex/;

इस मामले में उपयोगकर्ता को स्पष्ट रूप से परिभाषित करना होगा कि वह इसे type और const दोनों के रूप में चाहता है, इसलिए वास्तविक प्रकार की प्रणाली में कोई उत्सर्जन परिवर्तन नहीं होता है जब तक कि यह ऐसे संशोधक के साथ उपयोग नहीं किया जाता है। लेकिन अगर यह इसके साथ प्रयोग किया जाता है तो हम अभी भी बहुत सी गलतियों, कास्ट और कोड के दोहराव से बचने में सक्षम हैं, इसके लिए समान एमिट जोड़कर:

const Email = /email-regex/;

यह इस प्रस्ताव के लिए सिर्फ सुधार से भी बड़ा प्रतीत होता है, क्योंकि यह शायद कुछ इस तरह की अनुमति दे सकता है (उदाहरण Redux के साथ प्रोजेक्ट से है):

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

में परिवर्तित किया जा रहा है

export const type SOME_ACTION = 'SOME_ACTION';

मैंने कुछ इसी तरह के सुझाव खोजने की कोशिश की है लेकिन सफल नहीं हुआ। यदि यह एक समाधान हो सकता है और यदि आपको ऐसा विचार पसंद है, तो मैं इसके लिए डिजाइन प्रस्ताव और परीक्षण तैयार कर सकता हूं।

@DanielRosenwasser , आपके दूसरे मुद्दे के बारे में - मुझे नहीं लगता कि यह कभी होगा, क्योंकि मेरे सुझाव में संकलक केवल शाब्दिक के लिए रेगेक्स चलाता है और ऐसा नहीं लगता कि कोई ऐसा कुछ करेगा:

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

वैसे भी हम परीक्षण कर सकते हैं कि वास्तविक समय के प्रदर्शन को प्रभावित करने के लिए शाब्दिक कितना लंबा होना चाहिए और कुछ अनुमानी बनाना चाहिए जो उपयोगकर्ता को चेतावनी देगा कि अगर हम कुछ संपादक परिदृश्यों में इस परिस्थितियों का सामना करते समय इसकी जांच करने में असमर्थ हैं, लेकिन हम इसकी जांच करेंगे कि वह कब संकलित करेगा परियोजना। या कुछ और उपाय भी हो सकते हैं।

तीसरा सवाल के बारे में, मुझे यकीन है कि सही ढंग से सब कुछ समझते हैं कि नहीं कर रहा हूँ, लेकिन ऐसा लगता है कि regex इंजन के आधार पर चयन किया जाना चाहिए target से tsconfig यदि वे विभिन्न कार्यान्वयन है। कुछ और जांच की जरूरत है।

@DanielRosenwasser क्या कोई विचार है? प्रारंभिक प्रस्ताव के बारे में और पिछले एक के बारे में। हो सकता है कि मुझे दूसरे का अधिक विस्तृत अवलोकन करना पड़े, है ना?

@Igmat आपका प्रस्ताव सत्यापन को केवल स्ट्रिंग प्रकारों के साथ उपयोगी होने तक सीमित करता है। @rylphs के प्रस्ताव पर आपके क्या विचार हैं? यह सभी आदिम प्रकारों के लिए अधिक सामान्य सत्यापन की अनुमति देगा:

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

हालांकि मुझे संदेह है कि इस तंत्र को आदिम से परे गैर-आदिम प्रकारों तक विस्तारित करना बहुत अधिक होगा।
एक बिंदु, @DanielRosenwasser ने जो मुद्दा उठाया - रेगेक्स इंजन कार्यान्वयन को अलग-अलग करने के बारे में - बढ़ाया जाएगा: जावास्क्रिप्ट इंजन के आधार पर जिसके तहत टाइपस्क्रिप्ट कंपाइलर चल रहा है, सत्यापन फ़ंक्शन अलग-अलग काम कर सकता है।

@zspitz यह आशाजनक लग रहा है, लेकिन मेरी राय में यह संकलक के प्रदर्शन को बहुत अधिक प्रभावित कर सकता है, क्योंकि फ़ंक्शन किसी भी नियम द्वारा सीमित नहीं है और यह TS को कुछ ऐसे भावों की गणना करने के लिए मजबूर करेगा जो बहुत जटिल हैं या यहां तक ​​​​कि कुछ संसाधनों पर निर्भर हैं जो उपलब्ध नहीं हैं संकलन समय में।

@Igmat

क्योंकि फ़ंक्शन किसी भी नियम द्वारा सीमित नहीं है

क्या आपके मन में कुछ विशिष्ट उदाहरण हैं? शायद सत्यापन सिंटैक्स को टाइपस्क्रिप्ट के "सुरक्षित"/संकलन-समय-ज्ञात सबसेट तक सीमित करना संभव है।

उपयोगकर्ता द्वारा परिभाषित प्रकार के गार्ड को नए प्रकार को

// 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 अच्छा लग रहा है, लेकिन विस्तार के बारे में क्या?

क्या उन्हें बिल्कुल विस्तार योग्य होने की आवश्यकता है? क्या कोई टाइपस्क्रिप्ट डिज़ाइन सिद्धांत है जो इसकी मांग करता है? यदि नहीं, तो मेरे पास नाममात्र प्रकार होंगे @disjukr कुछ भी नहीं से सुझाव देते हैं, भले ही वे विस्तार योग्य न हों।

विस्तारशीलता आईएमएचओ प्राप्त करने के लिए हमें कुछ रचनात्मक की आवश्यकता होगी - हम यह निर्धारित नहीं कर सकते कि एक मनमानी प्रकार गार्ड (फ़ंक्शन) दूसरे मनमानी प्रकार के गार्ड का सबसेट है या नहीं।

हम एक प्रकार की अभिकथन मानसिकता का उपयोग करके अल्पविकसित "विस्तारशीलता" प्राप्त कर सकते हैं (मैं यह नहीं कह रहा हूं कि यह कुछ "बहुत रचनात्मक" है - मैं कह रहा हूं कि यहां एक स्टॉप-गैप है जब तक कि कोई व्यक्ति कुछ रचनात्मक के साथ नहीं आता):

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 के गैर-विस्तार योग्य तरीके से लागू करें।)

ऑफटॉपिक की तरह,
अल्पविराम से अलग की गई सूची के लिए आपको ^ और $ एंकर का उपयोग करना होगा (यह ज्यादातर मामलों में प्रासंगिक है जब आप कुछ स्ट्रिंग को सत्यापित करना चाहते हैं)। और एंकर पुनरावृत्ति से बचने में मदद करते हैं, आपके उदाहरण के लिए regexp /^((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: .....

केस का उपयोग करें: टाइपस्क्रिप्ट typestyle "टाइप-सेफ" सीएसएस शैलियों को लिखने के लिए समर्पित एक पुस्तकालय है। उपरोक्त प्रस्तावित कार्यक्षमता बहुत मदद करेगी, क्योंकि पुस्तकालय को रनटाइम पर उपयोग की जाने वाली विधियों को उजागर करना होता है, प्रस्तावित स्ट्रिंग रेगेक्स प्रकार इसके बजाय संकलन समय पर चेक कोड टाइप करने में सक्षम होंगे और डेवलपर्स को महान इंटेलिजेंस देंगे।

@DanielRosenwasser @alexanderbird @Igmat: IMO इस प्रस्ताव खेल से बदलती टाइपप्रति और वेब विकास के लिए किया जाएगा। वर्तमान में इसे लागू करने से क्या रोक रहा है?

मैं इस बात से सहमत हूं कि एक्सटेंडेबिलिटी और टाइप एमिशन बाकी फीचर के आड़े नहीं आने चाहिए। यदि उन पहलुओं पर कोई स्पष्ट रास्ता नहीं है, तो उन्हें बाद में लागू करें जब वहाँ हो।

मैं यहां आया क्योंकि मैं एक यूयूआईडी प्रकार देख रहा हूं, न कि एक स्ट्रिंग, इसलिए स्ट्रिंग को परिभाषित करने वाला रेगेक्स इस मामले में शानदार होगा + प्रकार की वैधता की जांच करने का एक तरीका (ईमेल.टेस्ट उदाहरण) भी सहायक होगा।

@skbergam मैं इसे एक बार फिर से लागू करने की कोशिश कर रहा हूं। लेकिन टीएस परियोजना वास्तव में बहुत बड़ी है और मेरे पास एक काम भी है, इसलिए लगभग कोई प्रगति नहीं है (मैंने केवल इस नई सुविधा के लिए परीक्षण बनाने में कामयाबी हासिल की है)। अगर किसी के पास टीएस को विस्तारित करने का अधिक अनुभव है तो किसी भी मदद की सराहना की जाएगी ...

दिलचस्प है कि यह प्रभावी रूप से नाममात्र प्रकार बनाता है, क्योंकि हम किसी भी दो गैर-समान रेगेक्स के बीच कोई उप-प्रकार/असाइनबिलिटी संबंध स्थापित करने में असमर्थ होंगे

@RyanCavanaugh पहले @maiermic ने टिप्पणी की

संपादित करें: ऐसा लगता है कि यह समस्या बहुपद समय में हल करने योग्य है (देखें नियमित अभिव्यक्तियों के लिए समावेशन समस्या)।

लेकिन यह काफी अच्छा नहीं हो सकता है? एक निश्चित रूप से उम्मीद करता है कि कई रेगेक्सपी रिश्ते नहीं हैं, लेकिन आप कभी नहीं जानते।

टाइप चेक के संबंध में, अगर हमें रेगेक्सप्स की नकल करना पसंद नहीं है, और typeof एक कॉन्स्ट पर्याप्त नहीं है (जैसे .d.ts फाइलें), TS valueof e बारे में कैसा महसूस करता है, जो उत्सर्जित करता है का शाब्दिक मूल्य e iff e एक शाब्दिक है, अन्यथा एक त्रुटि (और undefined तरह कुछ उत्सर्जित करता है)?

@maxlk भी ऑफ-टॉपिक लेकिन मैंने आपका रेगेक्स लिया और इसे अन्यथा मान्य इनपुट पर अनुगामी अल्पविराम से मेल नहीं खाने के लिए सुधार किया: /^((dog|cat|fish)(,(?=\b)|$))+$/ परीक्षण के साथ https://regex101.com/r/AuyP3g/1 । यह अल्पविराम के बाद एक शब्द वर्ण के लिए सकारात्मक लुकहेड का उपयोग करता है, जो पूर्व को एक DRY तरीके से पुन: सत्यापित करने के लिए मजबूर करता है।

नमस्ते!
इसकी स्थिति क्या है?
क्या आप निकट भविष्य में इस सुविधा को जोड़ेंगे? रोडमैप में इसके बारे में कुछ नहीं मिल रहा है।

@lgmat केवल lib.d.ts में उपलब्ध परिभाषाओं का उपयोग करके सिंटैक्स को सिंगल-लाइन एरो फ़ंक्शंस तक सीमित करने के बारे में कैसे?

क्या वे भयानक सुधार उपलब्ध हैं? शायद अल्फा रिलीज में कम से कम?

रेगेक्स मान्य प्रकार परीक्षण लिखने के लिए बहुत अच्छे हैं, हार्डकोडेड इनपुट को मान्य करना बहुत अच्छा होगा।

+1। हमारा उपयोग मामला बहुत आम है, हमें 'dd/mm/YYYY' जैसे स्ट्रिंग दिनांक प्रारूप की आवश्यकता है।

हालांकि जैसा कि प्रस्तावित है यह एक बहुत ही शानदार विशेषता होगी, इसमें क्षमता का अभाव है:

• आउटपुट हमेशा एक स्टिंग होता है (हालाँकि संकलन समय की जाँच की जाती है), संरचित वस्तु प्राप्त करने का कोई तरीका नहीं है
• व्याकरण रेगेक्सपी क्या कर सकता है, और वे बहुत कुछ नहीं कर सकते हैं, नियमित अभिव्यक्तियों की समस्या यह है कि वे नियमित हैं, उनका परिणाम एक सूची है, पेड़ नहीं, वे मनमाने ढंग से लंबे घोंसले के स्तर को व्यक्त नहीं कर सकते हैं
• पार्सर को टाइपस्क्रिप्ट व्याकरण के संदर्भ में व्यक्त किया जाना है, जो सीमित है और विस्तार योग्य नहीं है

बेहतर तरीका होगा आउटसोर्स पार्सिंग और एक प्लगइन को उत्सर्जित करना, जैसा कि # 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 में उपलब्ध परिभाषाओं का उपयोग करके सिंटैक्स को सिंगल-लाइन एरो फ़ंक्शंस तक सीमित करने के बारे में कैसे?

@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 अलग-अलग समाधान देखूंगा, एक तार के लिए और एक संख्याओं के लिए।

कुछ लोगों के लिए RegExp इसके प्रति प्रतिरक्षित है क्योंकि आप इसे दुर्भावनापूर्ण तरीके से उपयोग करने का एकमात्र तरीका कुछ बैकट्रैकिंग अभिव्यक्ति बनाना है। कहा जा रहा है, कुछ उपयोगकर्ता अनजाने में ऐसा कर सकते हैं, इसलिए, किसी प्रकार की सुरक्षा होनी चाहिए। मुझे लगता है कि ऐसा करने का सबसे अच्छा तरीका टाइमर होगा।

एक बिंदु, @DanielRosenwasser ने जो मुद्दा उठाया - रेगेक्स इंजन कार्यान्वयन को अलग-अलग करने के बारे में - बढ़ाया जाएगा: जावास्क्रिप्ट इंजन के आधार पर जिसके तहत टाइपस्क्रिप्ट कंपाइलर चल रहा है, सत्यापन फ़ंक्शन अलग-अलग काम कर सकता है।

यह सच है, यह बुरा है, लेकिन हम यह निर्दिष्ट करके हल कर सकते हैं कि regExp का कौन सा "आधुनिक" भाग हमें अपने कोडबेस के लिए चाहिए। यह सामान्य के लिए डिफ़ॉल्ट होगा (क्या यह ES3 है?) regexp, जो प्रत्येक नोड में काम करता है। और नए झंडे को सक्षम करने और दावे के पीछे देखने का विकल्प।

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`.

टाइपस्क्रिप्ट उन्नत RegExp का मूल्यांकन नहीं करेगा, यदि उसे नहीं बताया गया है। लेकिन मैं सुझाव दूंगा कि क्या हो रहा है और उन्नत RegExp जांच को कैसे सक्षम किया जाए, यह बताते हुए चेतावनी देनी चाहिए।

यदि उपयोगकर्ता ने उन्नत झंडे के साथ ध्वज सक्षम किया है और उसका नोड इसका समर्थन करता है।

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

यदि किसी उपयोगकर्ता ने उन्नत फ़्लैग के साथ फ़्लैग सक्षम किया है और उसका नोड इसका समर्थन करता है।

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

मुझे लगता है कि इसके बारे में जाने का यह एक उचित तरीका है।
प्रोग्रामर की टीमों में आमतौर पर NodeJS का एक ही संस्करण होता है या आसानी से अपग्रेड करने में सक्षम होते हैं क्योंकि उनके सभी कोडबेस किसी नए संस्करण वाले किसी के लिए काम कर रहे होते हैं।
सोलो प्रोग्रामर मक्खी पर आसानी से अनुकूलन कर सकते हैं,

इस मुद्दे की वर्तमान स्थिति क्या है? यह देखना वास्तव में अफ़सोस की बात है कि टाइपस्क्रिप्ट में इतनी बड़ी क्षमता और दर्जनों भयानक प्रस्ताव हैं, लेकिन वे डेवलपर्स से ज्यादा ध्यान नहीं देते हैं ...

AFAIK मूल प्रस्ताव एमिट सिंहावलोकन के अलावा अच्छा था जो कि एक नहीं है और वास्तव में इसकी आवश्यकता नहीं है, इसलिए इसे प्रस्ताव को अवरुद्ध नहीं करना चाहिए।

जिस मुद्दे को वह संबोधित करने का प्रयास कर रहा है उसे रेगेक्स अक्षर (जो कठिन नहीं होना चाहिए, क्योंकि वे प्रभावी रूप से स्ट्रिंग और संख्या अक्षर के बराबर हैं) और एक प्रकार ऑपरेटर patternof ( typeof समान) के परिचय द्वारा हल किया जा सकता है keyof ), जो एक रेगेक्स शाब्दिक प्रकार लेगा और एक _validated string_ प्रकार लौटाएगा। इस प्रकार इसका उपयोग किया जा सकता है:

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

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

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

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

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

@ m93a मैंने अतिरिक्त प्रकार के ऑपरेटर के साथ इस तरह के समाधान के बारे में नहीं सोचा था, जब प्रारंभिक प्रस्ताव पर काम कर रहा था।

मुझे प्रकारों के कारण उत्सर्जन प्रभाव को हटाने का यह दृष्टिकोण पसंद है, भले ही यह अधिक क्रियात्मक प्रतीत होता है।

और इससे मुझे यह पता चलता है कि इस प्रस्ताव को कैसे बढ़ाया जाए ताकि दोनों नए कीवर्ड जोड़ना छोड़ दें (जैसा कि आप सुझाव देते हैं) - आईएमओ हमारे पास पहले से ही बहुत बड़ी मात्रा में है और टाइप सिस्टम से उत्सर्जन प्रभाव नहीं है (जैसा कि मेरे प्रस्ताव में है)।

इसमें 4 कदम लगेंगे:

1. regexp-validated string literal प्रकार जोड़ें:
   TypeScript type Email = /some-long-email-regex/;
2. आइए कोर लिब में 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. conditional types सुविधा का उपयोग करके टाइप हेल्पर जोड़ें, जैसे InstanceType :
   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 कूल। आपका प्रस्ताव टाइपस्क्रिप्ट के लिए अधिक स्वाभाविक लगता है और संकलक में कम बदलाव की आवश्यकता है, यह शायद एक अच्छी बात है। मेरे प्रस्ताव का एकमात्र लाभ यह था कि रेगेक्स अक्षर स्ट्रिंग और संख्या अक्षर के समान ही महसूस करेंगे, यह कुछ के लिए भ्रमित हो सकता है:

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

लेकिन मुझे लगता है कि आपके प्रस्ताव की सादगी एक नुकसान से अधिक है।

संपादित करें: मुझे वास्तव में ValidatedStringType<R> की लंबाई पसंद नहीं है। यदि हमने मान्य स्ट्रिंग पैटर्न को कॉल करने का निर्णय लिया है, तो हम PatternOf<R> उपयोग कर सकते हैं। मैं यह नहीं कह रहा हूं कि आपके टाइप को टाइप करने में अधिक समय लगता है, ज्यादातर लोग सिर्फ पहले तीन अक्षर और हिट टैब टाइप करेंगे। इसका सिर्फ बड़ा कोड स्पैगेटिफिकेशन प्रभाव है।

@Igmat आपका समाधान विकास बिंदु से उत्कृष्ट है, लेकिन जैसा कि पठनीयता जाता है, यह संभावना के लिए बेहतर होगा जैसा कि @ m93a प्रस्तावित है। मुझे लगता है कि इसे आंतरिक रूप से उसी तरह से दर्शाया जा सकता है, लेकिन इसे उपयोगकर्ता को यथासंभव सरल रूप में प्रस्तुत किया जाना चाहिए।

@Akxe मुझे नहीं लगता कि एक बहुत ही विशिष्ट उपयोग केस हो।

@RyanCavanaugh क्या आप हमें इस पर अपनी राय बता सकते हैं? (विशेष रूप से मूल प्रस्ताव और चार अंतिम टिप्पणियां (इसे छोड़कर) धन्यवाद! :+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> कहना बेहतर होगा।

@ आमिर-अरद, दिलचस्प। इस मामले में interface RegExp कैसा दिखेगा?

@RyanCavanaugh मैं मूल प्रस्ताव को नए तरीके से फिर से लिख सकता हूं अगर यह मदद करेगा। क्या मुझे ऐसा करना चाहिए?

@ amir-arad आपका प्रस्तावित सिंटैक्स बाकी टाइपस्क्रिप्ट के विरोध में है। अब आप केवल प्रकार को सामान्य तर्क के रूप में पारित कर सकते हैं, मनमानी अभिव्यक्ति नहीं। आपका प्रस्तावित वाक्यविन्यास बेहद भ्रमित करने वाला होगा।

सामान्य प्रकारों के बारे में सोचें जैसे वे ऐसे कार्य हैं जो एक प्रकार लेते हैं और एक प्रकार वापस करते हैं। कोड के निम्नलिखित दो टुकड़े अर्थ और वाक्य रचना दोनों में बहुत करीब हैं:

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

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

आपका नया सिंटैक्स यह प्रस्तावित करने जैसा है कि जावास्क्रिप्ट में रेगेक्स को let all = String(.*) लिखा जाना चाहिए जो फ़ंक्शन कॉल सिंटैक्स का बदसूरत दुरुपयोग होगा। इसलिए मुझे नहीं लगता कि आपका प्रस्ताव ज्यादा मायने रखता है।

@ m93a मेरा सुझाव टाइप एनोटेशन के लिए था, जावास्क्रिप्ट के लिए नहीं।

@Igmat मेरे सिर के ऊपर से, कैसे के बारे में:

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

@ आमिर-अरद, क्षमा करें, मैं आपके सुझाव में अधिक मूल्यवान विवरण नहीं जोड़ सकता, लेकिन पहली नज़र में यह पूरे टीएस कंपाइलर में बहुत महत्वपूर्ण बदलाव जैसा दिखता है, क्योंकि string बहुत बुनियादी आदिम है।

भले ही मुझे कोई स्पष्ट समस्या दिखाई नहीं दे रही है, मुझे लगता है कि इस तरह के प्रस्ताव को और अधिक विस्तृत होना चाहिए और इसमें बहुत सारे मौजूदा परिदृश्य और इसके उद्देश्य का उचित औचित्य शामिल होना चाहिए।
आपका प्रस्ताव एक प्रकार जोड़ता है और एक आदिम प्रकार बदलता है, जबकि मेरा केवल एक प्रकार जोड़ता है।

दुर्भाग्य से, मैं इस तरह की सुविधा के लिए प्रस्ताव बनाने के लिए बहुत समय समर्पित करने के लिए तैयार नहीं हूं (यह भी, आपने देखा होगा कि टीएस में हर प्रस्ताव बिना किसी देरी के लागू नहीं किया गया है), लेकिन अगर आप इस पर काम करेंगे, तो मैं ' यदि आवश्यक हो तो आपको मेरी प्रतिक्रिया प्रदान करने में खुशी होगी।

यदि ये रेगेक्सपी-प्रकार वास्तविक नियमित अभिव्यक्ति थे (पर्ल-जैसे नियमित अभिव्यक्ति नहीं जो नियमित नहीं हैं) तो हम उन्हें नियतात्मक एफएसएम में अनुवाद कर सकते हैं और सभी संयोजनों और संयोजनों को प्राप्त करने के लिए उन पर कार्टेशियन उत्पाद निर्माण का उपयोग कर सकते हैं। बूलियन ऑपरेशंस के तहत रेगुलर एक्सप्रेशन बंद हैं।

इसके अलावा यदि स्ट्रिंग शाब्दिक प्रकार परमाणु नहीं थे, लेकिन संकलन-समय वर्ण सूचियों के रूप में दर्शाए गए थे, तो यह पुस्तकालयों में सभी ऑपरेटरों को लागू करने की अनुमति देगा। यह केवल प्रदर्शन को थोड़ा खराब करेगा।

संपादित करें: एक गलती ठीक

यह ध्यान में रखना कि मिथ्रिल वास्तव में इनका उपयोग कर सकता है, और सामान्य मामले में टाइप-सुरक्षित होना इसके बिना लगभग असंभव है। हाइपरस्क्रिप्ट और JSX सिंटैक्स दोनों के साथ यही स्थिति है। (हम दोनों का समर्थन करते हैं।)

• हमारे जीवनचक्र के हुक, oninit , oncreate , onbeforeupdate , onupdate , onbeforeremove , और onremove अपने स्वयं के हैं विशेष प्रोटोटाइप।
• DOM vnode पर ईवेंट हैंडलर सचमुच कुछ और हैं जो on , और हम ईवेंट श्रोता फ़ंक्शन और ईवेंट श्रोता ऑब्जेक्ट ( handleEvent विधियों के साथ) दोनों का समर्थन करते हैं, addEventListener साथ संरेखित करते हैं और removeEventListener ।
• हम उपयुक्त के रूप में चाबियों और रेफरी का समर्थन करते हैं।
• बाकी सब कुछ एक विशेषता या संपत्ति के रूप में माना जाता है, जो कि बैकिंग डीओएम नोड पर उनके अस्तित्व पर निर्भर करता है।

तो एक रेगेक्स-मान्य स्ट्रिंग प्रकार + प्रकार निषेध के साथ , हम DOM vnodes के लिए निम्न कार्य कर सकते हैं:

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

    // Control attributes
    key: PropertyKey;
}

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

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

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

(इस तरह के रेगेक्स से समूह निकालने में सक्षम होना भी अच्छा होगा, लेकिन मैं उस पर अपनी सांस नहीं रोकूंगा।)

संपादित करें: प्रस्ताव में कुछ महत्वपूर्ण विवरण स्पष्ट
संपादित करें 2: वास्तव में गणितीय रूप से सटीक होने के लिए तकनीकी बिट को सही करें।
संपादित करें 3: सिंगल-कैरेक्टर यूनियनों के सामान्य अभिनीत के लिए समर्थन जोड़ें

इसे और अधिक व्यावहारिक रूप से हल करने का प्रयास करने के लिए यहां एक ठोस प्रस्ताव दिया गया है: टेम्पलेट शाब्दिक प्रकार।

साथ ही, मुझे लगता है कि पूर्ण रेगेक्सप्स शायद एक अच्छा विचार नहीं है, क्योंकि इसे अन्य प्रकारों के साथ विलय करना उचित रूप से आसान होना चाहिए। शायद यह बेहतर हो सकता है: टेम्पलेट शाब्दिक प्रकार।

• `value` - यह सचमुच "value" बराबर है
• `value${"a" | "b"}` - यह सचमुच "valuea" | "valueb" बराबर है
• `value${string}` - यह कार्यात्मक रूप से regexp /^value/ , लेकिन "value" , "valuea" , और "valueakjsfbf aflksfief fskdf d" सभी इसके लिए असाइन करने योग्य हैं।
• `foo${string}bar` - यह कार्यात्मक रूप से regexp /^foo.*bar$/ , लेकिन इसे सामान्य करना थोड़ा आसान है।
• बेशक, कई प्रक्षेप हो सकते हैं। `foo${string}bar${string}baz` एक वैध टेम्पलेट शाब्दिक प्रकार है।
• इंटरपोलेशन का विस्तार string होना चाहिए , और यह पुनरावर्ती चाहिए । (दूसरी शर्त तकनीकी कारणों से है।)
• एक टेम्प्लेट शाब्दिक प्रकार A एक टेम्प्लेट शाब्दिक प्रकार B के लिए आबंटित करने योग्य है यदि और केवल तभी जब A के लिए असाइन किए जाने वाले स्ट्रिंग्स का सेट B लिए असाइन किए गए स्ट्रिंग्स के सेट का एक सबसेट है।

उपरोक्त के अलावा, एक विशेष starof T प्रकार मौजूद होगा, जहां T में केवल सिंगल-कैरेक्टर स्ट्रिंग शाब्दिक प्रकार होना चाहिए। 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?) - यह उपरोक्त Numeric प्रकार या इसके कुछ प्रकार को सांख्यिकीय रूप से ज्ञात base s के लिए वापस कर सकता है।
• +x , x | 0 , parseInt(x) , और इसी तरह - जब x को Numeric रूप में जाना जाता है जैसा कि ऊपर परिभाषित किया गया है, परिणामी प्रकार कर सकते हैं शाब्दिक संख्या प्रकार के रूप में उचित रूप से अनुमान लगाया जा सकता है।

और अंत में, आप इस तरह से मेल खाने वाले समूहों को निकाल सकते हैं: Key extends `on${infer EventName}` ? EventTypeMap[TagName][EventName] : never । टेम्पलेट निष्कर्षण मानता है कि यह हमेशा पूर्ण नामों के साथ काम कर रहा है, इसलिए आपको स्वैच्छिक समावेशन की खोज के लिए स्पष्ट रूप से ${string} इंटरपोलेशन का उपयोग करना होगा। यह गैर लालची है, इसलिए ` "foo.bar.baz" extends ${infer T}.${infer U} ? [T, U] : never रिटर्न ["foo", "bar.baz"] , न कि ["foo.bar", "baz"] ।

तकनीकी दृष्टिकोण से, कच्चे रेगेक्सप्स की तुलना में इसे लागू करना बहुत अधिक संभव है। जेएस रेगेक्सप्स भी नियमित नहीं हैं - वे बैक-रेफरेंस के साथ संदर्भ-संवेदनशील हो जाते हैं, और जब तक आप इनके साथ रिकर्सन को अवरुद्ध करते हैं, तब तक उनमें बहुत जटिलता शामिल होती है, टेम्पलेट शाब्दिक प्रकार प्रत्येक एक नियमित भाषा उत्पन्न करते हैं, एक वह अंतर्निहित सिद्धांत के साथ बहुत निकटता से संरेखित करता है (लेकिन इसके केवल एक सबसेट का समर्थन करता है)।

• खाली भाषा: ""
• संघ: "a" | "b"
• संयोजन: `${a}${b}`
• क्लेन स्टार (आंशिक): starof T ( T केवल एकल वर्ण और संघ शामिल हो सकते हैं।)

यह स्ट्रिंग सबटाइपिंग को सबग्राफ आइसोमोर्फिज्म समस्या के सबसे खराब स्थिति परिदृश्य की जांच कर सकता है, लेकिन यहां कुछ बड़े रिडीमिंग कारक हैं:

1. अब तक का सामान्य मामला छोटे परिमित तारों का संघ है, जिसे आप पेड़ों के साथ मॉडल कर सकते हैं। इसके साथ काम करना अपेक्षाकृत स्पष्ट है। (मैं उन्हें रस्सियों के रूप में शामिल करने की कोशिश करने की अनुशंसा नहीं करता, क्योंकि यह उपरोक्त मिलान एल्गोरिदम को जटिल करेगा, लेकिन सिंगल-कैरेक्टर यूनियनों को सामान्य करने के लिए यह बिल्कुल ठीक है और एक स्प्लिट + जॉइन में समान है।)

2. आप संपूर्ण एकीकृत प्रकार को एक निर्देशित ग्राफ़ के रूप में मॉडल कर सकते हैं, जहां:

   1. ऐसे वर्णों के तारांकित संघ सबग्राफ होते हैं जहां पैरेंट नोड में प्रत्येक वर्ण और सबग्राफ के प्रत्येक बच्चे के नोड्स दोनों के किनारे होते हैं, और प्रत्येक वर्ण में अन्य सभी वर्णों और सबग्राफ के सभी चाइल्ड नोड्स के किनारे होते हैं।
   2. बाकी ग्राफ में अन्य सभी संभावनाओं का प्रतिनिधित्व करने वाली एक निर्देशित पेड़ जैसी संरचना है।

   इस Math.SE चैट के अनुसार मैं संक्षेप में (लगभग यहां से शुरू कर रहा था ), मैंने पाया कि इस परिणामी ग्राफ में एक बाध्य जीनस (यानी अन्य किनारों पर कूदने की सीमित संख्या के साथ) दोनों होंगे और, कोई starof अनुपस्थित होगा टाइप समानता एक बहुपद-समय की समस्या को कम कर देती है और मान लीजिए कि आप यूनियनों को सामान्य करते हैं, यह भी बहुत धीमा नहीं है क्योंकि यह पेड़ समानता से कुछ हद तक तेज़ है। मुझे इस पूरे प्रस्ताव के लिए सामान्य मामले पर दृढ़ता से संदेह है (सबग्राफ आइसोमोर्फिज्म समस्या का एक सबसेट) उचित गुणांक के साथ बहुपद-समय भी है। (ऊपर लिंक किए गए विकिपीडिया लेख में "एल्गोरिदम" और संदर्भ अनुभागों में कुछ उदाहरण हैं जहां विशेष आवरण लागू हो सकते हैं।)




3. इन चाबियों में से कोई भी बड़ी होने की संभावना नहीं है, इसलिए यहां की अधिकांश वास्तविक रनटाइम लागत को अन्य चीजों द्वारा अभ्यास में परिशोधित किया जाता है। जब तक यह छोटी चाबियों के लिए तेज़ है, यह काफी अच्छा है।




4. तुलना किए जाने वाले सभी सबग्राफ कम से कम एक नोड साझा करते हैं: रूट नोड। (यह स्ट्रिंग की शुरुआत का प्रतिनिधित्व करता है।) तो यह नाटकीय रूप से समस्या स्थान को अपने आप कम कर देगा और बहुपद समय की जांच की गारंटी देगा।

और निश्चित रूप से, ऐसे प्रकारों के बीच प्रतिच्छेदन गैर-तुच्छ है , लेकिन मुझे लगता है कि उपरोक्त प्रतिबंधों के कारण समान रिडीमिंग कारक मौजूद हैं। विशेष रूप से, अंतिम प्रतिबंध इसे स्पष्ट रूप से बहुपद-समय करने के लिए बनाता है।

* गणितीय रूप से, जीनस को हमारे प्रोग्रामरों के लिए थोड़ा उल्टा परिभाषित किया गया है (बिना किसी छलांग के ग्राफ़ खींचने के लिए आपको सतह पर छेद करने की न्यूनतम संख्या), लेकिन एक सीमित जीनस (छिद्रों की सीमित संख्या) का तात्पर्य सीमित संख्या में कूद से है .

इस ठोस प्रस्ताव का उपयोग करते हुए, इस टिप्पणी से मेरे उदाहरण का अनुवाद

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

    // Control attributes
    key: PropertyKey;
}

interface HTMLTypeMap {
    // ...
}

interface HTMLEventMap {
    // ...
}

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

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

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

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

संपादित करें: यह लॉडश की _.get विधि और संबंधित विधियों का इसकी संपत्ति शॉर्टहैंड का उपयोग करके ठीक से टाइप करने में सक्षम होगा, जैसे इसकी _.property(path) विधि और इसकी _.map(coll, path) शॉर्टहैंड। शायद कई अन्य हैं जिनके बारे में मैं भी नहीं सोच रहा हूं, लेकिन शायद यह सबसे बड़ा है जिसके बारे में मैं सोच सकता हूं। (मैं पाठक के लिए एक अभ्यास के रूप में उस प्रकार के कार्यान्वयन को छोड़ने जा रहा हूं, लेकिन मैं आपको आश्वस्त कर सकता हूं कि यह इसके संयोजन और सशर्त प्रकारों की सामान्य चाल के साथ तत्काल अनुक्रमित रिकॉर्ड के साथ संभव है, {0: ..., 1: ...}[Path extends "" ? 0 : 1] जैसा कुछ

मेरी सिफारिश है कि हम टाइप प्रदाताओं को लागू करने के अपने प्रयासों पर ध्यान केंद्रित करें, जिसका उपयोग रेगेक्स प्रकारों को लागू करने के लिए किया जा सकता है।

रेगेक्स प्रकारों को सीधे लागू करने के बजाय प्रदाता क्यों टाइप करें? चूंकि

1. यह एक अधिक सामान्य समाधान है जो टाइपस्क्रिप्ट में कई नई संभावनाएं जोड़ता है जिससे डेवलपर्स के व्यापक समूह से समर्थन प्राप्त करना आसान हो जाता है जो रेगेक्स स्ट्रिंग प्रकारों में मूल्य देखते हैं।
2. टाइपस्क्रिप्ट रेपो मालिक इस विचार के लिए खुले हैं, और सही प्रस्ताव की प्रतीक्षा कर रहे हैं। देखें #३१३६

एफ # में ओपन सोर्स रेगेक्स टाइप प्रदाता है।

प्रकार प्रदाताओं के बारे में कुछ जानकारी: https://link.medium.com/0wS7vgaDQV

कोई कल्पना कर सकता है कि एक बार टाइप प्रोवाइडर लागू हो जाने के बाद और रेगेक्स टाइप प्रोवाइडर को एक ओपन सोर्स लाइब्रेरी के रूप में लागू किया जाता है, तो कोई इसका इस्तेमाल इस तरह करेगा:

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

@AlexLeung मुझे विश्वास नहीं है कि जाने का सही तरीका है, कम से कम इस अनुरोध के लिए नहीं।

• टाइपस्क्रिप्ट संरचनात्मक रूप से टाइप किया गया है, नाममात्र टाइप नहीं किया गया है, और स्ट्रिंग शाब्दिक हेरफेर के लिए, मैं उस संरचनात्मक भावना को बनाए रखना चाहता हूं। इस तरह के प्रदाता एक नाममात्र का string उपप्रकार बनाएंगे जहां RegexProvider</^foo$/> को "foo" बराबर नहीं माना जाएगा, बल्कि इसका एक मामूली उपप्रकार माना जाएगा। इसके अलावा, RegexProvider</^foo$/> और RegexProvider</^fo{2}$/> को दो अलग-अलग प्रकारों के रूप में माना जाएगा, और यह ऐसी चीज है जिसका मैं प्रशंसक नहीं हूं। इसके बजाय मेरा प्रस्ताव सीधे उनके मूल में तारों के साथ एकीकृत होता है, औपचारिक भाषा मान्यता के सिद्धांत द्वारा सीधे सूचित किया जाता है ताकि यह सुनिश्चित हो सके कि यह स्वाभाविक रूप से फिट बैठता है।
• मेरे साथ, आप न केवल स्ट्रिंग्स को जोड़ सकते हैं, बल्कि स्ट्रिंग्स के कुछ हिस्सों को Key extends `on${infer K}` ? K : never या यहां तक ​​​​कि Key extends `${Prefix}${infer Rest}` ? Rest : never माध्यम से भी निकाल सकते हैं। टाइप प्रदाता इस कार्यक्षमता की पेशकश नहीं करते हैं, और कोई स्पष्ट तरीका नहीं है कि अगर ऐसी कार्यक्षमता को जोड़ा जाए तो इसे कैसे करना चाहिए ।
• मेरा वैचारिक स्तर पर काफी सरल है: मैं सिर्फ सुझाव दे रहा हूं कि हम स्ट्रिंग संयोजन प्रकार जोड़ते हैं और, सशर्त प्रकारों के आरएचएस के लिए, इसके व्युत्क्रम को निकालने की क्षमता। मैं यह भी प्रस्ताव करता हूं कि यह एक regexp /.*/ की जगह लेने के लिए string साथ एकीकृत हो। इसके लिए किसी एपीआई परिवर्तन की आवश्यकता नहीं है, और दो सैद्धांतिक रूप से जटिल भागों से अलग, जो ज्यादातर कोड आधार के बाकी हिस्सों से अलग हो जाते हैं, यह गणना करते हुए कि क्या एक टेम्पलेट शाब्दिक प्रकार दूसरे को असाइन करने योग्य है और एक स्ट्रिंग से एक टुकड़ा निकालने के समान है, यदि सरल नहीं है , लागू करने के लिए।

BTW, मेरा प्रस्ताव अभी भी उस PhoneNumber उदाहरण को भी टाइप कर सकता है। यह थोड़ा और वर्बोज़ है, लेकिन मैं डेटा को मॉडल करने की कोशिश कर रहा हूं जो पहले से ही टीएस भूमि में है, न कि डेटा जो कहीं और मौजूद है (एफ # के प्रकार प्रदाता सबसे उपयोगी हैं)। (यह ध्यान देने योग्य है कि यह तकनीकी रूप से यहां संभावित फोन नंबरों की पूरी सूची में विस्तारित होगा।)

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

RegexProvider^foo$/> और RegexProvider^fo{2}$/> को दो अलग-अलग प्रकारों के रूप में माना जाएगा

टाइप प्रदाताओं को कुछ equals या compare विधि के कार्यान्वयन की आवश्यकता हो सकती है, ताकि रेगेक्स प्रकार प्रदाता के प्रकार प्रदाता लेखक परिभाषित कर सकें कि उपरोक्त दोनों मामले समकक्ष प्रकार हैं। टाइप प्रदाता लेखक अपनी इच्छानुसार संरचनात्मक या नाममात्र टाइपिंग को लागू कर सकता है।

शायद आपके स्ट्रिंग अक्षर प्रकार को एक प्रकार प्रदाता के रूप में भी कार्यान्वित करना संभव होगा। मुझे नहीं लगता कि वाक्यविन्यास समान हो सकता है, लेकिन आप एक प्रकार के प्रदाता के साथ निकट हो सकते हैं जो तर्कों की एक चर संख्या लेता है।

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

@AlexLeung लेकिन क्या आपके प्रकार के लिए "123-456-7890" प्रकार असाइन करने योग्य है? (यदि ऐसा है, तो यह कार्यान्वयन को जटिल बना देगा और चेकर को बहुत धीमा कर देगा।)

अर्ध-संबंधित चर्चा से संबंधित, क्या होगा यदि प्रकार निश्चित लंबाई का नहीं है (जैसे फ़ोन नंबर)? एक स्थिति जहां मैं हाल ही में इसका उपयोग करना पसंद करूंगा, वह है thread_{number} प्रारूप के कमरे के नाम को संग्रहित करना।

इस तरह के मूल्य से मेल खाने वाला रेगेक्स thread_[1-9]\d* । जो प्रस्तावित किया जा रहा है, इस तरह के प्रारूप से मेल खाना संभव (या संभव भी) नहीं लगता है। इस स्थिति में मान का संख्यात्मक भाग _any_ लंबाई शून्य से अधिक हो सकता है।

@jhpratt मैंने starof ("0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9") /^\d*$/ के रूप में इसे समायोजित करने के लिए अपने प्रस्ताव को संशोधित किया, क्योंकि इसमें केवल एक छोटे से बदलाव की आवश्यकता थी। यह उसी तरह अनुकूलित करता है जैसे string /^[\u0000-\uFFFF]*$/ रूप में अनुकूलित करता है, इसलिए मैंने आगे बढ़ने और इसे सामान्यीकृत करने का निर्णय लिया।

मैं इससे आगे starof का विस्तार नहीं करना चाहता, जैसे कि मनमानी गैर-पुनरावर्ती यूनियनों को स्वीकार करना, कम्प्यूटेशनल जटिलता चिंताओं के कारण: सत्यापित करना कि क्या दो मनमानी नियमित अभिव्यक्ति * समकक्ष हैं बहुपद स्थान या बहुपद समय में किया जा सकता है ( दोनों को न्यूनतम डीएफए में परिवर्तित करें और तुलना करें - सामान्य तरीका, लेकिन अभ्यास में बहुत धीमा), लेकिन अभ्यास में दोनों तरीके बहुत धीमे हैं और AFAICT आपके पास दोनों तरीकों से नहीं हो सकता है। स्क्वायरिंग के लिए समर्थन जोड़ें (जैसे 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 && ... }

प्रारंभिक शुरुआत के रूप में, टाइपप्रति केवल सत्यापन कार्यों को स्वीकार कर सकता है जो:

• एक एकल तर्क है, जिसे "आधार" प्रकार का होना आवश्यक/माना जाता है
• केवल संदर्भ चर जो सत्यापनकर्ता फ़ंक्शन में परिभाषित हैं
• एक मान वापस करें (जिसे सत्यापन प्रक्रिया में बूल के लिए मजबूर किया जाएगा)

टाइपस्क्रिप्ट कंपाइलर को सत्यापित करने के लिए उपरोक्त शर्तें आसान लगती हैं, और एक बार उन शर्तों को मान लेने के बाद, कार्यान्वयन की बहुत जटिलता दूर हो जाएगी।

इसके अलावा, यदि आवश्यक हो तो प्रारंभिक दायरे को एक प्रबंधनीय आकार तक सीमित करना:

• सत्यापन कार्यों को केवल मूल प्रकारों (स्ट्रिंग, संख्या) के सबसेट में जोड़ा जा सकता है

मुझे नहीं लगता कि यह अंतिम प्रतिबंध इतना आवश्यक होगा, लेकिन यदि कोई प्रश्न है कि क्या यह होगा, तो मुझे नहीं लगता कि इस पर बहस करने में अधिक समय व्यतीत करना उचित होगा, क्योंकि उपरोक्त सीमा के साथ एक समाधान अभी भी वास्तविक दुनिया के उपयोग के मामलों की एक विशाल श्रृंखला को हल करेगा। इसके अलावा, मुझे उपरोक्त सीमाओं का थोड़ा नकारात्मक पहलू दिखाई देता है क्योंकि बाद में उन्हें आराम देना एक सरल और प्राकृतिक विस्तार होगा जिसके लिए मूल वाक्यविन्यास में कोई बदलाव की आवश्यकता नहीं होगी और केवल संकलक द्वारा भाषा समर्थन की चौड़ाई का विस्तार होगा।

@mewalig इसका मतलब यह होगा कि रनटाइम फ़ंक्शन की तरह दिखने वाला कुछ वास्तव में रनटाइम पर निष्पादित नहीं होगा, लेकिन संकलन समय पर (और हर बार जब आप असाइनमेंट की जांच करना चाहते हैं)। ये फ़ंक्शन रनटाइम (चर, फ़ंक्शंस)

इसके अलावा आप आम तौर पर नहीं चाहते हैं कि संकलक आपके द्वारा फेंके गए कुछ भी चलाए, विशेष रूप से बुरी तरह अनुकूलित कार्यों या पूरी तरह से दुर्भावनापूर्ण while(true){} । यदि आप मेटा-प्रोग्रामिंग चाहते हैं, तो आपको इसे स्मार्ट तरीके से डिजाइन करना होगा। बस बेतरतीब ढंग से रनटाइम कोड को संकलन समय पर चलाने की अनुमति देना "PHP तरीका" होगा।

अंत में, आपके द्वारा प्रस्तावित सिंटैक्स सामान्य पैटर्न को बदल देता है

let runtime: types = runtime;

(अर्थात बृहदान्त्र के बाद के प्रकार) अंदर से बाहर, प्रभावी रूप से

type types = types: runtime;

जो भयानक है। तो आपके प्रस्ताव के लिए धन्यवाद, लेकिन यह निश्चित रूप से एक बुरा विचार है।

ये फ़ंक्शन रनटाइम (चर, फ़ंक्शंस)

बेशक वे कर सकते हैं , अगर संकलक के पास ईसीएमएस्क्रिप्ट रनटाइम उपलब्ध है ( tsc करता है, बीटीडब्लू!)। आपके पास स्पष्ट रूप से fetch() बनाम रनटाइम सेमेन्टिक्स के संकलन-समय शब्दार्थ के साथ एक अस्पष्टता समस्या है, लेकिन यही पुनरावृत्ति के बारे में है।

बस बेतरतीब ढंग से रनटाइम कोड को संकलन समय पर चलाने की अनुमति देना "PHP तरीका" होगा।

यह काफी हद तक C++ constexpr functions के समान है , जो ठीक हैं। इसका समाधान यह है कि constexpr केवल constexpr उपयोग कर सकता है, लेकिन सब कुछ constexpr उपयोग कर सकता है। तब आपके पास constexpr -कंपाइल-टाइम फाइल सिस्टम के लिए फाइल सिस्टम के समतुल्य संस्करण हो सकते हैं जो काफी शक्तिशाली हो सकते हैं।

वाक्यविन्यास भी मेरे लिए लगभग ठीक दिखता है: एलएचएस एक प्रकार है, निश्चित रूप से आरएचएस भी किसी प्रकार का एक प्रकार है। मेरी समस्या इस बारे में अधिक है कि आप "आधार" प्रकार के पिछले प्रकारों की रचना कैसे करेंगे, लेकिन यह सब भी हल करने योग्य है।

तो आपके प्रस्ताव के लिए धन्यवाद, लेकिन यह निश्चित रूप से एक बुरा विचार है।

यह एक बुरा विचार हो सकता है, लेकिन अभी के लिए मैं सिर्फ एक बहुत ही अनिर्दिष्ट विचार देख रहा हूं जिसके लिए टाइपस्क्रिप्ट के लक्ष्यों से बहुत दूर भटकने की आवश्यकता होगी। इसका मतलब यह नहीं है कि इसके समान कोई अच्छा विचार नहीं हो सकता है!

इस सुविधा के बारे में चर्चा अभी रुकती दिख रही है ( पीआर बंद है और डिजाइन नोट्स टीम के अनुसार _इस पर तब तक प्रतिबद्ध नहीं होना चाहते जब तक कि हमारे पास नाममात्र प्रकार और सामान्यीकृत अनुक्रमणिका हस्ताक्षर न हों, और हमें पता होना चाहिए कि वे क्या दिखते हैं।_)।

वैसे भी, मैं वर्तमान पीआर के लिए एक और काल्पनिक विस्तार का प्रस्ताव देना चाहता हूं जो रेगेक्स पैटर्न निष्कर्षण का समर्थन करेगा ( @isiahmeadows ने अपना प्रस्ताव प्रस्तुत किया, लेकिन ईमानदार होने के लिए मैं अब इसके चारों ओर अपना सिर लपेट नहीं सकता ...)

मुझे वास्तव में वर्तमान पीआर पसंद है और मैं अपने प्रस्ताव को उसी पर आधारित करूंगा। मैं सामान्य प्रकार के तर्कों के अनुमान के आधार पर सिंटैक्स का प्रस्ताव देना चाहता हूं जो हमारे पास कार्यों के लिए है (और सशर्त प्रकार 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/lodash फ़ंक्शन प्राप्त करें

आप टाइप-सुरक्षित "स्ट्रिंग पथ" गेटटर को कार्यान्वित कर सकते हैं ताकि यह कोड काम करे:

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

लेकिन शायद इसे हल करने की आवश्यकता होगी यह है कि अगर हम संभव के तय अधिकतम संख्या के लिए कई भार के से बचना चाहते हैं get के "गहराई"।

1. मैप किए गए प्रकारों में निकाले गए पैरामीटर का उपयोग करें।

उदाहरण के लिए यदि हम ऐसा कुछ करने में सक्षम होंगे https://github.com/Microsoft/TypeScript/issues/12754। तब हमारे पास फ़ंक्शन को उलटने की संभावना हो सकती है (दिए गए प्रकार के सभी गुणों से कुछ उपसर्ग/प्रत्यय को हटा दें)। संपत्ति के लिए नई कुंजी चुनने के लिए इसे शायद मैप किए गए टाइप किए गए वाक्यविन्यास के कुछ और सामान्यीकृत रूप को पेश करने की आवश्यकता होगी (उदाहरण के लिए { [ StripAsyncSuffix<P> for P in K ] : T[P] } जैसे वाक्यविन्यास, किसी ने पहले से ही ऐसा कुछ

शायद अन्य उपयोग के मामले भी होंगे। लेकिन मुझे लगता है कि अधिकांश इन दो प्रकारों में फिट होंगे (1. प्रदान की गई स्ट्रिंग अक्षर के आधार पर उचित प्रकार का पता लगाना, 2. इनपुट प्रकार के संपत्ति नामों को नए परिभाषित प्रकार के नए संपत्ति नामों में बदलना)

यह कुछ ऐसा है जिससे हम कर सकते हैं।

मैं वर्तमान में यूआरएल को मान्य करने में सक्षम होने के लिए कस्टम लिंट नियम बना रहा हूं - हालांकि, यह बहुत आसान होगा यदि हम वैकल्पिक पैरा को परिभाषित कर सकते हैं - जिसके लिए हमारे आईडी को सत्यापित करने में सक्षम होने के लिए रेगेक्स की आवश्यकता होती है

सामान्य तौर पर, यह हमें हमारे कोड बेस में प्रॉप्स की वैधता पर जोर देने के लिए बहुत अधिक शक्ति प्रदान करेगा

क्या टाइप प्रोवाइडर, टेम्प्लेट स्ट्रिंग लिटरल या अन्य सुझावों पर कोई हलचल है? यह इतना अच्छा उपकरण होगा।

इसके लिए मेरा समाधान वर्तमान में इस तरह के मार्कर इंटरफ़ेस का उपयोग करना है।

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

हालाँकि, जावास्क्रिप्ट 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
    }
}

मैं दोहराता हूँ: यह एक नॉन-स्टार्टर है । टाइपप्रति में प्रकार composable कर रहे हैं और प्रकार से जे एस उत्सर्जक इस दुनिया में संभव नहीं है। अब तक के सबसे

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

चौराहों पर प्रतिबंध

वास्तव में सामान्य प्रकार और रेगेक्स-मान्य प्रकार वास्तव में भिन्न होते हैं, इसलिए हमें नियमों की आवश्यकता होती है कि कैसे उनके संघों और चौराहों को सही ढंग से संभालें।

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

टाइपस्क्रिप्ट चौराहों की तात्कालिकता पर त्रुटि नहीं कर सकता है, इसलिए यह किसी भी अंतिम डिजाइन का हिस्सा नहीं होगा।

श्रमदक्षता शास्त्र

कुल मिलाकर हमारा सबसे महत्वपूर्ण निष्कर्ष यह है कि हम कुछ ऐसा चाहते हैं जहां आप एक ही RegExp को दो बार नहीं लिख रहे हैं (एक बार वैल्यू स्पेस में, एक बार टाइप स्पेस में)।

उत्सर्जन प्रकार के बारे में उपरोक्त चिंताओं को देखते हुए, सबसे यथार्थवादी समाधान यह है कि आप मूल्य स्थान में अभिव्यक्ति लिखेंगे:

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

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

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

आप अभी भी टाइप स्पेस में RegExp लिख सकते हैं, लेकिन कोई रनटाइम सत्यापन उपलब्ध नहीं होगा और किसी भी गैर-उपयोग के लिए पुन: परीक्षण या दावा की आवश्यकता होगी:

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

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

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

उपयोग के मामलों का संग्रह और स्पष्टीकरण

एक नए प्रकार के प्रकार के लिए, हम आदर्श रूप से ऐसे कई उदाहरण देखना चाहेंगे जहां:

• हल की जा रही समस्या का कोई बेहतर विकल्प नहीं है (प्रशंसनीय विकल्पों सहित जो अभी तक भाषा में नहीं हैं)
• वास्तविक कोडबेस में सार्थक आवृत्ति के साथ समस्या उत्पन्न होती है
• प्रस्तावित समाधान उस समस्या को अच्छी तरह हल करता है

साहित्य का संकलन-समय सत्यापन

यह धागा उपयोग के मामलों की एक विस्तृत विविधता का तात्पर्य है; ठोस उदाहरण अधिक दुर्लभ रहे हैं। परेशानी की बात यह है कि इनमें से कई उदाहरण पूर्ण नहीं लगते हैं - वे एक RegExp का उपयोग करते हैं जो मान्य इनपुट को अस्वीकार कर देगा।

• फ़ॉन्ट रंग - AFAIK कुछ भी जो हेक्स रंगों को स्वीकार करता है वह भी स्वीकार करता है जैसे "सफेद" या "स्काईब्लू"। यह rgb(255, 0, 0) सिंटैक्स को भी गलत तरीके से अस्वीकार करता है।
• एसएसएन, ज़िप, आदि - ठीक है, लेकिन आपके कोड में शाब्दिक एसएसएन या ज़िप कोड क्यों हैं? क्या यह वास्तव में नाममात्र के प्रकारों की आवश्यकता है? क्या होता है यदि आपके पास स्ट्रिंग्स का उप-वर्ग है जिसे RegExp द्वारा सटीक रूप से वर्णित नहीं किया जा सकता है? "प्रतिस्पर्धी प्रस्ताव" देखें
  
  
  
  • पूर्णांक - "3e5" को गलत तरीके से अस्वीकार करता है
  
  
  • ईमेल - यह आमतौर पर एक बुरा विचार माना जाता है । फिर भी, आपके कोड में ईमेल पता स्ट्रिंग अक्षर हैं?
  
  
  • CSS बॉर्डर स्पेक्स - मुझे विश्वास हो सकता है कि एक स्टैंडअलोन लाइब्रेरी उस DSL का वर्णन करने के लिए एक सटीक RegEx प्रदान कर सकती है जिसका वह स्वयं समर्थन करता है
  
  
  • परीक्षण लिखना - यह वह जगह है जहां हार्डकोडेड इनपुट कुछ समझ में आता है, हालांकि यह लगभग एक काउंटरपॉइंट है क्योंकि आपका टेस्ट कोड शायद बहुत सारे अमान्य इनपुट प्रदान कर रहा है
  
  
  • दिनांक प्रारूप - कैसे/क्यों? Date पास इसके लिए एक कंस्ट्रक्टर है; यदि इनपुट रनटाइम के बाहर से आता है तो आप केवल नाममात्र प्रकार चाहते हैं
  
  
  • यूआरआई - आप कल्पना कर सकते हैं कि fetch host को http(s?): साथ नहीं होने के लिए निर्दिष्ट करेगा
  
  

TODO: कृपया वास्तविक पुस्तकालय कार्यों की पहचान करके हमारी सहायता करें जो RegExp प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं।

एक चिंता "सटीकता" है - क्या होता है जब कोई व्यक्ति निश्चित रूप से निश्चित रूप से टाइप किया जाता है और पुस्तकालय में प्रत्येक फ़ंक्शन में RegExp प्रकार जोड़ता है, इस प्रकार प्रत्येक गैर-शाब्दिक आमंत्रण को तोड़ देता है? इससे भी बदतर, परिभाषा फ़ाइल लेखकों को इसके उपभोक्ताओं के साथ बिल्कुल सहमत होना होगा कि सत्यापन RegExp की "सही वर्तनी" क्या है।
ऐसा लगता है कि यह हमें जल्दी से एक टॉवर ऑफ बैबेल की स्थिति में ले जाता है, जहां प्रत्येक पुस्तकालय का अपना संस्करण होता है जो URL के रूप में योग्य होता है, जो होस्ट नाम के रूप में योग्य होता है, ईमेल के रूप में क्या योग्य होता है, आदि, और कोई भी जो दो पुस्तकालयों को जोड़ता है। संकलक को संतुष्ट करने के लिए प्रकार के दावे डालना या रेगेक्स की प्रतिलिपि बनाना है।

रनटाइम चेक का प्रवर्तन

चेक के बारे में कुछ चर्चा हुई है जहां हम यह सुनिश्चित करना चाहते हैं कि किसी फ़ंक्शन के तर्कों को पूर्व रेगेक्स द्वारा मान्य किया गया है, जैसे fn पहले के एर्गोनॉमिक्स अनुभाग में। यह सीधा और मूल्यवान लगता है, अगर RegEx जिसके खिलाफ परीक्षण की आवश्यकता है, वह प्रसिद्ध है। यह एक बड़ा "अगर" है, हालांकि - मेरी यादों में, मुझे एक पुस्तकालय याद नहीं है जो सत्यापन रेगेक्स प्रदान करता है। यह सत्यापन कार्य प्रदान कर सकता है - लेकिन इसका तात्पर्य है कि प्रदान की जाने वाली सुविधा नाममात्र या टैग प्रकार है, रेगेक्स प्रकार नहीं।

इस आकलन के प्रति-साक्ष्य का स्वागत है।

संपत्ति कुंजी/रेगेक्स स्ट्रिंग इंडेक्सर्स

कुछ पुस्तकालय संपत्ति के नाम के अनुसार वस्तुओं का इलाज करते हैं। उदाहरण के लिए, रिएक्ट में हम किसी भी प्रोप पर टाइप लागू करना चाहते हैं जिसका नाम 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 प्रकारों की भी आवश्यकता होगी? अधिक विचारों के लिए "संकलन-समय" जाँच अनुभाग देखें।

इसके विपरीत, मान लें कि हमारे पास 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 सिंटैक्स का समर्थन करते हैं। टाइपस्क्रिप्ट कंपाइलर कहाँ चलता है, इस पर निर्भर करते हुए, कुछ कोड मान्य या अमान्य हो सकते हैं, जो नई RegExp सुविधाओं को पार्स करने की रनटाइम की क्षमताओं के अनुसार हो सकता है। व्यवहार में, अधिकांश नई RegExp सुविधाएँ काफी गूढ़ हैं या समूह मिलान से संबंधित हैं, जो यहाँ उपयोग के अधिकांश मामलों के साथ संरेखित नहीं लगती हैं।

प्रदर्शन

RegExes एक असीमित मात्रा में काम कर सकता है और एक बड़ी स्ट्रिंग के साथ मिलान करने से मनमाने ढंग से बड़ी मात्रा में काम हो सकता है। उपयोगकर्ता पहले से ही अन्य माध्यमों से खुद को डॉस कर सकते हैं, और दुर्भावनापूर्ण रूप से अक्षम RegExp लिखने की संभावना नहीं है।

सबटाइपिंग ( /\d*/ -> /.*/ ?), संघ, प्रतिच्छेदन, और निर्वासन

सिद्धांत रूप में /\d+/ के ज्ञेय उप प्रकार है /.+/ । माना जाता है कि एल्गोरिदम यह निर्धारित करने के लिए मौजूद हैं कि क्या एक RegExp दूसरे के शुद्ध उपसमुच्चय (कुछ बाधाओं के तहत) से मेल खाता है, लेकिन स्पष्ट रूप से अभिव्यक्ति को पार्स करने की आवश्यकता होगी। व्यवहार में हम 100% ठीक हैं क्योंकि RegExpes उनके मेल के आधार पर निहित उपप्रकार संबंध नहीं बनाते हैं; यह शायद और भी बेहतर है।

यूनियन और इंटरसेक्शन ऑपरेशंस "बॉक्स से बाहर" काम करेंगे, जब तक कि असाइनिबिलिटी संबंधों को सही ढंग से परिभाषित किया गया हो।

टाइपस्क्रिप्ट में, जब दो आदिम प्रकार एक चौराहे पर "टकराते हैं", तो वे never । जब दो RegExpes को प्रतिच्छेद किया जाता है, तो हम दो अभिव्यक्तियों के प्रतिच्छेदन से मेल खाने वाला एक नया RegExp बनाने की कोशिश करने के बजाय इसे केवल /a/ & /b/ रूप में रखेंगे। never कोई कमी नहीं होगी हमें यह साबित करने के लिए एक एल्गोरिदम की आवश्यकता होगी कि कोई स्ट्रिंग दोनों पक्षों को संतुष्ट नहीं कर सकती है (यह पहले वर्णित एक के समानांतर समस्या है: सबटाइपिंग)।

अगला कदम

संक्षेप में, अगले चरण हैं:

• रेगेक्स-नामित संपत्ति कुंजियों के लिए एक अलग समस्या दर्ज करें AKA रेगेक्स स्ट्रिंग अनुक्रमणिका
• स्ट्रिंग अक्षर के संकलन-समय सत्यापन के लिए ठोस और प्रशंसनीय उपयोग के मामले प्राप्त करें
  
  
  
  • उदाहरण: निश्चित रूप से टाइप किए गए या अन्य पुस्तकालयों में कार्यों की पहचान करें जो इससे अत्यधिक लाभान्वित होंगे
  
  
• समझें कि गैर-शाब्दिक सत्यापन के लिए नाममात्र/टैग/ब्रांडेड प्रकार अधिक लचीला और व्यापक रूप से लागू समाधान हैं या नहीं
• उन पुस्तकालयों की पहचान करें जो सत्यापन प्रदान कर रहे हैं RegExes पहले से ही

केस का उपयोग करें: हाइपरस्क्रिप्ट (https://github.com/hyperhype/hyperscript) जैसे फंक्शन
एक हाइपरस्क्रिप्ट फ़ंक्शन को आमतौर पर h('div#some-id') तरह कहा जाता है
एक रेगेक्स-ईश पैटर्न मैचर h के रिटर्न प्रकार को निर्धारित करने की अनुमति देगा जो उदाहरण के मामले में HTMLDivElement होगा।

यदि टाइप सिस्टम स्ट्रिंग अक्षर जोड़ने में सक्षम होगा, तो मूल रूप से कोई भी सीएसएस संपत्ति टाइप-सुरक्षित हो सकती है

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

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

CSS चयनकर्ताओं को भी मान्य किया जा सकता है ( element.class#id - मान्य, div#.name - अमान्य)

यदि कैप्चरिंग समूह काम करेंगे (किसी तरह) तो लोदाश की get विधि टाइप-सुरक्षित हो सकती है

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

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

यह भी एक बात हो सकती है:

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

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

केस का प्रयोग करें: हाइपरस्क्रिप्ट (हाइपरहाइप/हाइपरस्क्रिप्ट) जैसे फ़ंक्शंस

वह रेगेक्स कैसा दिखेगा, या यह क्या सत्यापन प्रदान करेगा? क्या यह रेगेक्स-आधारित फ़ंक्शन ओवरलोडिंग के लिए है?

FWIW पुस्तकालय नामांकित टैग नामों को स्वीकार करता है और मनमाने टैग नामों पर भी कार्य करता है

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

यह वर्ग और आईडी मानों के असीमित मिश्रण को भी स्वीकार करता है

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

CSS चयनकर्ताओं को भी मान्य किया जा सकता है

CSS चयनकर्ताओं को रेगुलर एक्सप्रेशन द्वारा सत्यापित नहीं किया जा सकता

वह रेगेक्स कैसा दिखेगा, या यह क्या सत्यापन प्रदान करेगा? क्या यह रेगेक्स-आधारित फ़ंक्शन ओवरलोडिंग के लिए है?

ओपी नहीं, लेकिन मुझे लगता है, हाँ, HTMLDocument#createElement() ओवरलोड जैसा कुछ, उदाहरण के लिए:

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

मुझे यकीन है कि आरई अधूरे हैं। ध्यान दें कि यह CSS चयनकर्ताओं को मान्य करने का एक विशेष मामला है, जिसका उपयोग कई संदर्भों में नियमित रूप से किया जाता है। उदाहरण के लिए, यदि आप एक जटिल चयनकर्ता का उपयोग कर रहे हैं तो HTMLDocument.querySelector() लिए HTMLElement को फ़ॉलबैक के रूप में वापस करना बिल्कुल ठीक है।

मैं उत्सुक हूं कि गैर-ओवरलोडिंग उदाहरण हैं जो व्यवहार्य और उपयोगी दोनों हैं, हालांकि।

TODO: कृपया वास्तविक पुस्तकालय कार्यों की पहचान करके हमारी सहायता करें जो RegExp प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं।

मेरा उपयोग मामला वह है जिसे मैंने सीसीएक्सटी पुस्तकालय में इस टिप्पणी में समझाया है जहां मेरे पास तार हैं जो TickerSymbol s का प्रतिनिधित्व करते हैं। मुझे वास्तव में परवाह नहीं है कि क्या उन्हें रेगेक्स पैटर्न के लिए चेक किया गया है, लेकिन मैं चाहता हूं कि उन्हें string उप-प्रकार के रूप में माना जाए, इसलिए मुझे अधिक सख्त असाइनमेंट, पैरामीटर प्रकार की जांच आदि मिलती है। मैंने इसे पाया जब मैं कार्यात्मक प्रोग्रामिंग कर रहा हूं तो बहुत उपयोगी हो, इसके साथ मैं संकलन-समय पर टिकरसिंबोल, मुद्राएं, संपत्ति इत्यादि को आसानी से ट्रैक कर सकता हूं जहां रन-टाइम पर वे केवल सामान्य तार होते हैं।

@omidkrad ऐसा लगता है कि आपको नाममात्र प्रकार की आवश्यकता है, न कि रेगेक्स-मान्य प्रकार।

@ m93a मेरे मामले में मैं नाममात्र के प्रकारों के साथ ठीक हो

CSS चयनकर्ताओं को भी मान्य किया जा सकता है

CSS चयनकर्ताओं को रेगुलर एक्सप्रेशन द्वारा सत्यापित नहीं किया जा सकता

ठीक है, अगर रेगेक्सपी हमें उन्हें एक साथ सिलाई करने में सक्षम बनाता है तो हम सीएसएस रेगेक्स की प्रतिलिपि बना सकते हैं ..., है ना?

(ड्राफ्ट) सीएसएस टाइप किया गया ऑब्जेक्ट मॉडल

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

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

कड़े टाइप किए गए CSS मॉडल का उपयोग करने की इच्छा को संभावित रूप से कम करता है।

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

@RyanCavanaugh विशेष रूप से ^([^#\.\[\]]+) (डिफ़ॉल्ट "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' ) का वर्णन करने के लिए यूनियनों का उपयोग करने का प्रयास करते हैं, तो यह इसके बजाय गूंगा हो जाएगा संघ में यूआरएल और विधि प्रकारों के साथ संयुक्त होने पर केवल string तक, जिसका अर्थ है कि हम पहली कॉल में दिए गए प्रकार के आधार पर स्वचालित रूप से रिटर्न प्रकार का अनुमान नहीं लगा सकते हैं।

@Ovyerus रेगेक्स प्रकार आपकी मदद कैसे करेंगे? आप क्या लिखने की उम्मीद करेंगे? आप ओवरलोड या सशर्त प्रकारों के साथ बेंट के व्यवहार के समान कुछ मॉडल कर सकते हैं।

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

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

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

ओह, मैं अस्पष्ट था क्षमा करें, मेरा मानना ​​​​है कि आधार यूआरएल का पता लगाने के लिए एक स्ट्रिंग की शुरुआत में 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 रूप में समाप्त होता है। इसे केवल एक स्ट्रिंग के रूप में होने से "अनुचित रूप से" मेल खाता है कि तुला कैसे काम करता है, क्योंकि यह ^http: या ^https: की उपस्थिति की जांच करता है ताकि यह निर्धारित किया जा सके कि इसे आधार यूआरएल के रूप में क्या उपयोग करना चाहिए।

यदि हमारे पास रेगेक्स प्रकार थे, तो मैं बेसयूआरएल को type BaseUrl = /^https?:/ रूप में परिभाषित कर सकता था, और यह आदर्श रूप से उन स्ट्रिंग्स को ठीक से सत्यापित करेगा जो HTTP विधि या प्रतिक्रिया एन्कोडिंग नहीं हैं, साथ ही उन्हें string में अवशोषित नहीं करेंगे। प्रकार।

बिल्कुल, मैं वही हूं।

--
प्रोकोप सिमेक

20 अक्टूबर 2019 को 03:23:30 बजे, माइकल मिशेल ([email protected])
लिखा था:

ओह, मैं अस्पष्ट था क्षमा करें, मेरा मानना ​​​​है कि मेरी समस्या अधिक थी
मिलान http(s): आधार URL का पता लगाने के लिए एक स्ट्रिंग की शुरुआत में।

बेंट के हस्ताक्षर की तर्ज पर अधिक हैं

टाइप करें HttpMethods = 'GET' | 'पैच' | ...टाइप करें StatusCode = number;type BaseUrl = string; // यह वह जगह है जहां मुझे आदर्श रूप से यह देखने की आवश्यकता होगी कि क्या कोई स्ट्रिंग http(s) से मेल खाती है: टाइप हैडर = {[x: स्ट्रिंग]: कोई भी; };
प्रकार विकल्प = HttpMethods | StatusCode | बेसयूआरएल | शीर्षलेख;
फ़ंक्शन तुला (... args: विकल्प []): RequestFunctionफ़ंक्शन तुला (... args: (विकल्प | 'json') []): RequestFunction// और इसी तरह

हालांकि एक स्ट्रिंग के रूप में BaseUrl होने से HttpMethods को अवशोषित किया जाता है और वापस आ जाता है
यूनियनों को टाइप करें, जो केवल स्ट्रिंग के रूप में समाप्त होता है। इसे सिर्फ एक स्ट्रिंग के रूप में रखना
यह भी "गलत तरीके से" मेल खाता है कि तुला कैसे काम करता है, क्योंकि यह उपस्थिति की जांच करता है
^http: या ^https: यह निर्धारित करने के लिए कि इसे आधार के रूप में क्या उपयोग करना चाहिए
यूआरएल.

अगर हमारे पास रेगेक्स प्रकार थे, तो मैं बेसयूआरएल को बेसयूआरएल = / ^ https?: / के रूप में परिभाषित कर सकता था।
और यह आदर्श रूप से उन स्ट्रिंग्स को ठीक से सत्यापित करेगा जो HTTP विधि नहीं हैं या
प्रतिक्रिया एन्कोडिंग, साथ ही उन्हें स्ट्रिंग प्रकार में अवशोषित नहीं करना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/TypeScript/issues/6579?email_source=notifications&email_token=ABJ3U4JNK3V5MV4DJH73ZU3QPOXJFA5CNFSM4BZLAVSKYY3PNVWWK3TUL52HS4DFVREXG43VMVKA#KTNORZGO542111
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABJ3U4PHBXO4766LK7P7UXDQPOXJFANCNFSM4BZLAVSA
.

सोचा था कि मेरे पास उपयोग के मामले में एक फ़ंक्शन में पैरामीटर प्रकारों का पता लगाना था।

मूल रूप से मेरे पास एक पहचानकर्ता का प्रतिनिधित्व करने वाली स्ट्रिंग का एक अच्छी तरह से परिभाषित रेगेक्स प्रारूप है। मैं सज्जाकारों का उपयोग कर सकता था, लेकिन एक विस्तारित स्ट्रिंग प्रकार मुझे फ़ंक्शन में पारित पहचानकर्ता का प्रतिनिधित्व करने के लिए एक प्रकार का उपयोग करने देगा।

दोहराने के लिए, हमें जावास्क्रिप्ट कोड के उदाहरणों की आवश्यकता है जिसे आप टाइप करके लिखना चाहते हैं - अन्यथा हम केवल अनुमान लगा सकते हैं कि आप क्या मॉडल करने का प्रयास कर रहे हैं (और क्या इसे मॉडल करने का कोई तरीका है)।

@DanielRosenwasser नीचे कोड का एक उदाहरण है जिसके बारे में हम टाइपिंग को लागू करना चाहते हैं। http://www.typescriptlang.org/play/index.html#code/C4TwDgpgBAqjCSARKBeKBnYAnAlgOwHMBYAKFIGMAbAQ3XVnQiygG9SoOoxcA3a4aJn45yULBGoATAPZ5KIKAFtq + GIywAuWAmRoA5NQCcEAAwBGQwCMArAFoAZtYBMAdlsAWcvYActw2ZM7JzNJF28TCCcANgtLPXZOAHpErl5 + QWBhUXEpWXklFTw1Ji04JFQoMycAZihkqAA5AHkAFSgAQQAZTqaAdQBRRASOeu4cPgEMTOARMQkZOQVlVXVSnQq9PGlgW2pbAFd9nEk9OpSAZQAJJphO5Ga2gCF + ju6 + वाह ++ बीबीएल-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 तथ्य यह है कि आप एक नियमित अभिव्यक्ति के साथ एक यूयूआईडी का वर्णन करने में एक स्ट्रिंग होता है .

तो 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 एक यूयूआईडी वापस नहीं करता है, यह फेंकता है या देता है is UUID -> true ।
इसलिए मैं इस फ़ंक्शन का उपयोग यूयूआईडी को इस तरह से mainUser पर असाइन करने के लिए नहीं कर सकता

@RyanCavanaugh हम चाहते हैं कि इन्हें

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

इसके लिए बहुत अधिक जटिल प्रकार की परिभाषा की आवश्यकता होगी, जहां हमें कस्टम प्रकार की जांच विफलता संदेश की आवश्यकता होगी ताकि उपयोगकर्ताओं को यह पता लगाने में मदद मिल सके कि यह चेक टाइप करने में विफल क्यों हुआ।

अन्य हाइपरस्क्रिप्ट लाइब्रेरी और हाइपरस्क्रिप्ट-आधारित फ्रेमवर्क जैसे प्रतिक्रिया-हाइपरस्क्रिप्ट में भी समान चिंताएँ हैं।

उम्मीद है ये मदद करेगा!

@isiahmeadows आपके लिए कुछ प्रकार के चयनकर्ता स्ट्रिंग बिल्डर का उपयोग करने का बेहतर तरीका है, जो सही टाइपिंग के साथ ब्रांडेड स्ट्रिंग लौटाएगा। पसंद:

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

@anion155 वहां m("div", {...attrs}, ...children) साथ उपयोग करूंगा हाइपरस्क्रिप्ट चीनी में से कोई भी नहीं (टाइप करने में आसान, प्रक्रिया में बहुत आसान), लेकिन इसके बारे में बहुत कुछ करने के लिए अब बहुत देर हो चुकी है।

मेरे पास कहने के लिए बहुत कुछ है। हालाँकि, मैं अधीर हूँ। इसलिए, मैं एक बार में अपने विचारों को थोड़ा सा जारी करूंगा।

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

"सटीकता" के बारे में (यार, मुझे वह शब्द पसंद है),
मुझे नहीं लगता कि हमें इसके बारे में ज्यादा चिंता करनी चाहिए।

प्रकार प्रणाली पहले से ही पूर्ण ट्यूरिंग है।
इसका मूल रूप से मतलब है कि हम बहुत सी चीजों के बारे में अति-सटीक हो सकते हैं।
(जैसे, सभी SQL को मॉडलिंग करना? बेशर्म प्लग = P)

लेकिन आप (बहुत से) लोगों को पूरी तरह से बाहर जाते हुए नहीं देखते हैं, और सभी प्रकार के ऑपरेटरों का पागल तरीके से उपयोग करते हैं जो पुस्तकालयों को एक दूसरे के साथ संगत होने से रोकते हैं। मुझे यह सोचना अच्छा लगता है कि पुस्तकालय के लेखक पर्याप्त स्तर के होते हैं... है ना?

ऐसा अक्सर नहीं होता है कि मैंने स्ट्रिंग-पैटर्न प्रकार/रेगेक्स-मान्य स्ट्रिंग प्रकारों की कामना की है, लेकिन उन्होंने निश्चित रूप से मेरे कोड बेस की प्रकार की सुरक्षा को बढ़ाने में मदद की होगी।

उदाहरण

मेरे सिर के ऊपर से, मैं एक हालिया उदाहरण के बारे में सोच सकता हूं। (वहाँ एक गुच्छा और भी है लेकिन मैं एक भुलक्कड़ प्राणी हूँ)

स्ट्राइप के एपीआई (एक भुगतान प्रसंस्करण मंच) के साथ एकीकृत करते समय, वे ch_ का उपयोग charge -संबंधित पहचानकर्ताओं के लिए, re_ लिए refund -संबंधित पहचानकर्ताओं आदि के लिए करते हैं।

उन्हें PatternOf</^ch_.+/> और PatternOf</^re_.+/> साथ एन्कोड करना अच्छा होता।

इस तरह, टाइपो बनाते समय,

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

मुझे एक त्रुटि मिलेगी,

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

जितना मैं नाममात्र/टैग किए गए प्रकारों से प्यार करता हूं, वे कहीं अधिक अनौपचारिक और त्रुटि-प्रवण हैं।
मैं हमेशा नाममात्र/टैग किए गए प्रकारों को अंतिम उपाय के रूप में देखता हूं, क्योंकि इसका मतलब है कि ऐसा कुछ है जो टीएस टाइप सिस्टम मॉडल नहीं कर सकता है।

साथ ही, टैग किए गए प्रकार प्रेत प्रकारों के लिए बहुत अच्छे होते हैं।
नाममात्र प्रकार मूल रूप से कभी उपयोगी नहीं होते हैं।
(ठीक है, मैं पक्षपाती हो सकता हूं। वे केवल 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

उस ओर देखो।

• स्ट्रिंग अक्षर के लिए
• स्ट्रिंग शाब्दिक बाधा पर काबू पाने के बाद, यह बहुत बुरा नहीं है... है ना?

लेकिन इस प्रस्ताव के लिए मुख्य उपयोग-मामला स्ट्रिंग अक्षर है।
तो, यह एक भयानक विकल्प है।

स्ट्रक्चरल टैग प्रकार...

संरचनात्मक टैग प्रकार नाममात्र प्रकार से बहुत अलग नहीं हैं...

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

उस ओर देखो।

• स्ट्रिंग अक्षर के लिए
• स्ट्रिंग शाब्दिक बाधा पर काबू पाने के बाद, यह बहुत बुरा नहीं है... है ना?

लेकिन इस प्रस्ताव के लिए मुख्य उपयोग-मामला स्ट्रिंग अक्षर है।
तो, यह एक भयानक विकल्प है।

साथ ही, यह संरचनात्मक टैग प्रकार उदाहरण नाममात्र प्रकार के उदाहरण का एक शाब्दिक (हे, पन) कॉपी-पेस्ट है।

फर्क सिर्फ इतना है कि किस प्रकार StripeChargeId और StripeRefundId घोषित किए जाते हैं।

भले ही कोड मूल रूप से समान है, संरचनात्मक प्रकार नाममात्र प्रकारों से बेहतर हैं। (मैं इसे अगली पोस्ट में स्पष्ट करूँगा, मैं कसम खाता हूँ)।

निष्कर्ष

यह इस टिप्पणी के लिए सिर्फ एक निष्कर्ष है! मेरे समग्र विचारों का निष्कर्ष नहीं!

स्ट्रिंग-पैटर्न प्रकार/रेगेक्स-मान्य स्ट्रिंग प्रकार नाममात्र/संरचनात्मक टैग प्रकारों की तुलना में अधिक एर्गोनोमिक हैं। उम्मीद है, मेरे सरल उदाहरण बहुत अधिक काल्पनिक नहीं थे, यह पर्याप्त रूप से प्रदर्शित किया है।

निष्कर्ष (अतिरिक्त)

जितना संभव हो, एक आदिम प्रकार का सबसेट लेने के तरीकों को हमेशा नाममात्र/संरचनात्मक टैग/मूल्य-वस्तु प्रकारों पर प्राथमिकता दी जानी चाहिए।

आदिम प्रकारों का सबसेट लेने के उदाहरण,

• string शाब्दिक
• number शाब्दिक ( NaN, Infinity, -Infinity छोड़कर)
• boolean शाब्दिक
• bigint शाब्दिक
• यहां तक ​​कि unique symbol भी केवल symbol सबसेट ले रहा है

उपरोक्त उदाहरणों में से, केवल boolean "पर्याप्त सीमित" है। इसके केवल दो मान हैं।
डेवलपर true और false शाब्दिक होने से संतुष्ट हैं क्योंकि पूछने के लिए और कुछ नहीं है।

number प्रकार परिमित-ईश है लेकिन इसके बहुत सारे मूल्य हैं, हम इसे अनंत भी मान सकते हैं।
हम किन शाब्दिकों को निर्दिष्ट कर सकते हैं, इसमें भी छेद हैं।

यही कारण है कि श्रेणी संख्या प्रकार, और NaN, Infinity, -Infinity मुद्दे इतने लोकप्रिय हैं, और पॉप अप करते रहते हैं। एक अनंत सेट से मूल्यों का एक छोटा परिमित सेट निर्दिष्ट करने में सक्षम होना पर्याप्त नहीं है।

किसी श्रेणी को निर्दिष्ट करना सबसे आम/प्राकृतिक विचारों में से एक है जब किसी को अनंत सेट के बड़े परिमित/अनंत उपसमुच्चय को निर्दिष्ट करने की आवश्यकता होती है।

bigint प्रकार मूल रूप से अनंत है, केवल स्मृति द्वारा सीमित है।

यह श्रेणी संख्या प्रकार के मुद्दे की लोकप्रियता में भी योगदान देता है।

string प्रकार मूल रूप से अनंत है, केवल स्मृति द्वारा सीमित है।

और यही कारण है कि यह स्ट्रिंग-पैटर्न प्रकार/रेगेक्स-मान्य स्ट्रिंग प्रकार मुद्दा इतना लोकप्रिय है।

रेगेक्स निर्दिष्ट करना किसी के पास आने के लिए सबसे आम/प्राकृतिक विचारों में से एक है जब उन्हें अनंत सेट के बड़े परिमित/अनंत उपसमुच्चय को निर्दिष्ट करने की आवश्यकता होती है।

symbol प्रकार... यह भी अनंत है। और असीम भी, बहुत ज्यादा।

लेकिन symbol प्रकार के तत्व लगभग हर तरह से एक दूसरे से काफी हद तक असंबंधित हैं। और, इसलिए, किसी ने भी यह पूछने के लिए कोई मुद्दा नहीं बनाया है, "क्या मेरे पास symbol एक बड़ा परिमित/अनंत उपसमुच्चय निर्दिष्ट करने का कोई तरीका हो सकता है?"।

ज्यादातर लोगों के लिए, यह सवाल समझ में भी नहीं आता है। ऐसा करने का कोई सार्थक तरीका नहीं है (दाएं?)

हालाँकि, केवल आदिम के सबसेट घोषित करने में सक्षम होना बहुत उपयोगी नहीं है। हमें भी जरूरत है,

• आगे के काम के बिना सही प्रकार के साहित्य को असाइन करने योग्य होना चाहिए

शुक्र है, TS इसे अनुमति देने के लिए पर्याप्त समझदार है।

false से (arg : false) => void पास करने में असमर्थ होने की कल्पना करें!

• संकुचित करने के अंतर्निहित तरीके

  फिलहाल, इन शाब्दिकों के लिए, हमारे पास == और === को संकुचित करने के अंतर्निहित तरीके हैं।

  कल्पना कीजिए कि प्रत्येक शाब्दिक के लिए एक नए प्रकार का गार्ड लिखने की आवश्यकता है!

नाममात्र/संरचनात्मक टैग/मूल्य-वस्तु प्रकारों के साथ समस्या यह है कि वे मूल रूप से उपरोक्त दो मानदंडों को पूरा करने में विफल होते हैं। वे आदिम प्रकारों को भद्दे प्रकारों में बदल देते हैं जो काफी वस्तु प्रकार नहीं होते हैं, लेकिन उन्हें वैसे भी वस्तु प्रकारों की तरह संभाला जाना चाहिए।

श्रमदक्षता शास्त्र

ठीक है, यहां स्ट्रिंग-पैटर्न बनाम नाममात्र बनाम संरचनात्मक टैग प्रकारों पर अधिक विस्तार है।

ये तर्क https://github.com/microsoft/TypeScript/issues/15480 पर भी लागू होते हैं।

क्रॉस-लाइब्रेरी संगतता

नाममात्र प्रकार क्रॉस-लाइब्रेरी संगतता में सबसे खराब हैं।
यह दो पुस्तकालयों में unique symbol का उपयोग करने और उन्हें इंटरऑपरेट करने की कोशिश करने जैसा है।
यह बस नहीं किया जा सकता है।
आपको बॉयलरप्लेट टाइप गार्ड, या ट्रस्ट-मी-ऑपरेटर ( 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 };

फिर आपको बॉयलरप्लेट टाइप गार्ड, या ट्रस्ट-मी-ऑपरेटर ( 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) उपयोग कर सकते हैं। ट्रस्ट-मी-ऑपरेटर ( as ) का उपयोग करने की आवश्यकता नहीं है।

हालाँकि, आपको अभी भी अभिकथन गार्डों के लिए बॉयलरप्लेट की आवश्यकता होगी।

यदि प्रकार को क्रॉस-लाइब्रेरी संगतता की आवश्यकता नहीं है, तो स्ट्रिंग-पैटर्न प्रकारों का उपयोग करना सही है, और बहुत ही एर्गोनोमिक भी है।

यदि आपको क्रॉस-लाइब्रेरी संगतता की आवश्यकता है, तो स्ट्रिंग-पैटर्न प्रकार अभी भी संरचनात्मक टैग प्रकारों से बेहतर हैं! मेरी बात सुनो।

यदि मॉडलिंग किया जा रहा डोमेन अच्छी तरह से समझा जाता है, तो यह बहुत संभावना है कि एकाधिक, अलग-अलग पुस्तकालय लेखक एक ही रेगेक्स लिखना समाप्त कर देंगे। संरचनात्मक टैग प्रकारों के साथ, वे सभी टैग में जो भी गुण और प्रकार चाहते हैं उसे लिख सकते हैं।

यदि जो कुछ भी मॉडल किया जा रहा है उसके लिए मानक निर्दिष्ट स्ट्रिंग प्रारूप हैं, तो मूल रूप से यह गारंटी दी जाती है कि सभी पुस्तकालय लेखक एक ही रेगेक्स लिखेंगे! यदि वे एक अलग रेगेक्स लिखते हैं, तो वे वास्तव में मानक का पालन नहीं कर रहे हैं। क्या आप उनके पुस्तकालय का उपयोग करना चाहते हैं? संरचनात्मक टैग प्रकारों के साथ, वे अभी भी सब कुछ लिख सकते हैं। (जब तक कोई संरचनात्मक टैग प्रकार मानक शुरू नहीं करता है, जिसकी हर कोई परवाह करेगा? योग्य)

क्रॉस-संस्करण संगतता

हमेशा की तरह, क्रॉस-वर्जन संगतता में नाममात्र प्रकार सबसे खराब होते हैं।
ओह, आपने अपनी लाइब्रेरी को एक पैच, या मामूली संस्करण टक्कर दी?
प्रकार की घोषणा अभी भी वही है?
कोड अभी भी वही है?
नहीं। वे विभिन्न प्रकार हैं।

स्ट्रक्चरल टैग प्रकार अभी भी सभी संस्करणों (यहां तक ​​कि प्रमुख संस्करणों) में असाइन करने योग्य हैं, जब तक कि टैग प्रकार संरचनात्मक रूप से समान है।

स्ट्रिंग-पैटर्न प्रकार अभी भी सभी संस्करणों (यहां तक ​​​​कि प्रमुख संस्करण) में असाइन करने योग्य हैं, जब तक कि रेगेक्स समान है।

या हम यह निर्धारित करने के लिए केवल एक पीएसपीएसीई-पूर्ण एल्गोरिदम चला सकते हैं कि रेगेक्स समान हैं या नहीं? हम यह भी निर्धारित कर सकते हैं कि रेगेक्स के कौन से उप-वर्ग सबसे आम हैं और उनके लिए अनुकूलित समकक्ष एल्गोरिदम चलाते हैं ... लेकिन यह बहुत प्रयास की तरह लगता है।

रेगेक्स उपप्रकार जांच के लिए अच्छा होगा, और निश्चित रूप से स्ट्रिंग-पैटर्न प्रकारों का उपयोग अधिक एर्गोनोमिक बना देगा। ठीक उसी तरह जैसे रेंज सबटाइप चेक से नंबर रेंज टाइप प्रपोजल को फायदा होगा।

[संपादित करें]
इस टिप्पणी में,
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 के बारे में अधिक जानकारी

टाइपस्क्रिप्ट चौराहों की तात्कालिकता पर त्रुटि नहीं कर सकता है, इसलिए यह किसी भी अंतिम डिजाइन का हिस्सा नहीं होगा।

मुझे नहीं पता कि लोग चौराहों पर प्रतिबंध क्यों लगाना चाहते थे, लेकिन आप बिल्कुल सही कह रहे हैं कि इस पर प्रतिबंध लगाने का कोई मतलब नहीं है।

इस प्रकार हर अशाब्दिक आह्वान को तोड़ना?

खैर, हर गैर-शाब्दिक आह्वान नहीं।

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 प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं।

आपका विचार है कि नाममात्र/चिह्नित प्रकार गैर-शाब्दिक उपयोग के लिए पर्याप्त हैं।
इसलिए, कोई भी उपयोग मामला जो गैर-शाब्दिक उपयोग दिखाता है वह पर्याप्त नहीं है, क्योंकि नाममात्र/चिह्नित प्रकार इसे कवर करते हैं।

हालाँकि, हमने देखा है कि, गैर-शाब्दिक उपयोग के लिए भी,

• नाममात्र/संरचनात्मक टैग प्रकार क्रॉस-लाइब्रेरी/संस्करण संगतता समस्याओं से ग्रस्त हैं
• नाममात्र/संरचनात्मक टैग प्रकारों के लिए बॉयलरप्लेट की मात्रा स्ट्रिंग-पैटर्न प्रकारों के लिए बॉयलरप्लेट की तुलना में काफी अधिक है

साथ ही, ऐसा लगता है कि शाब्दिक उपयोग के मामले आपके लिए असंतोषजनक रहे हैं, क्योंकि वे ईमेल सत्यापन जैसी मूर्खतापूर्ण चीजों की कोशिश करते हैं और करते हैं, या रेगेक्स का उपयोग करते हैं जो पर्याप्त सटीक नहीं हैं।

परीक्षण लिखना - यह वह जगह है जहां हार्डकोडेड इनपुट कुछ समझ में आता है, हालांकि यह लगभग एक काउंटरपॉइंट है क्योंकि आपका टेस्ट कोड शायद बहुत सारे अमान्य इनपुट प्रदान कर रहा है

एक अच्छा उपयोग मामला लाया गया रन-टाइम परीक्षण लिख रहा था। और आप सही हैं, कि उन्हें रन-टाइम परीक्षणों के लिए भी बहुत सारे अमान्य इनपुट फेंकना चाहिए।

लेकिन स्ट्रिंग-पैटर्न प्रकारों का समर्थन न करने का कोई कारण नहीं है। ऐसा हो सकता है कि वे किसी निश्चित फ़ाइल में मान्य इनपुट का परीक्षण करना चाहते हैं और गलती से अमान्य इनपुट दे देते हैं।

लेकिन, क्योंकि उन्हें टाइप गार्ड या ट्रस्ट-मी-ऑपरेटर ( as ) या वैल्यू ऑब्जेक्ट का उपयोग करना होता है, अब उन्हें यह जानने के बजाय कि परीक्षण समय से पहले विफल हो जाएगा, उन्हें रन-टाइम त्रुटि मिलेगी। .

रन-टाइम परीक्षणों के लिए ट्रस्ट-मी-ऑपरेटर ( as ) का उपयोग करना केवल अमान्य इनपुट के परीक्षण के लिए आरक्षित होना चाहिए। जब वैध इनपुट का परीक्षण करना चाहते हैं, तो यह अधिक स्पष्ट है कि नाममात्र/संरचनात्मक टैग प्रकार के लिए शाब्दिक असाइन करने के लिए हैक की आवश्यकता नहीं है।

यदि वे भविष्य में कभी भी रेगेक्स बदलते हैं, तो यह अच्छा होगा यदि उनके परीक्षण अब भी चलने में विफल हो जाते हैं, क्योंकि असाइनमेंट के मुद्दों के कारण। अगर वे अपने परीक्षणों में हर जगह सिर्फ हमें as करते हैं, तो उन्हें तब तक पता नहीं चलेगा जब तक वे परीक्षण नहीं चलाते।

और अगर पुस्तकालय लेखक अपने पुस्तकालय को डॉगफूड करते समय हर जगह सिर्फ as का उपयोग करता है ... डाउनस्ट्रीम उपभोक्ताओं का क्या? क्या उन्हें हर जगह as का उपयोग करने और नए संस्करण में अपग्रेड करते समय रन-टाइम समस्याओं में भाग लेने का मोह नहीं होगा?

स्ट्रिंग-पैटर्न प्रकारों के साथ, हर जगह as का उपयोग करने का कम कारण है और लाइब्रेरी लेखक और डाउनस्ट्रीम उपभोक्ता दोनों ही आसानी से परिवर्तनों को तोड़ने के बारे में जानेंगे।

(एक तरह की लंबी हवा लेकिन मुझे उम्मीद है कि मेरे कुछ अंक मिल गए हैं)।

इसके अलावा, मैं बहुत सारे संकलन-समय परीक्षण लिखता हूं (और मुझे पता है कि टीएस टीम भी ऐसा करती है)।

यह अच्छा होगा यदि मैं परीक्षण कर सकता हूं कि एक निश्चित string शाब्दिक मेरे संकलन-समय परीक्षणों में एक रेगेक्स चेक विफल/पास करेगा। फिलहाल, मेरे पास इन चीजों के लिए संकलन-समय परीक्षण नहीं हो सकते हैं और इसके बजाय रन-टाइम परीक्षण का उपयोग करने की आवश्यकता है।

और अगर यह मेरे संकलन-समय परीक्षणों में विफल रहता है/पास करता है, तो मुझे विश्वास होगा कि डाउनस्ट्रीम उपभोक्ता उन स्ट्रिंग अक्षर (या समान वाले) का उपयोग कर सकते हैं और उनसे सही तरीके से व्यवहार करने की उम्मीद कर सकते हैं।

ऐसा लगता है कि यह जल्दी से हमें बाबेल के टॉवर की स्थिति में ले जाता है ...

यह वास्तव में नाममात्र/संरचनात्मक टैग प्रकारों का उपयोग करने के बारे में और भी सच है। जैसा कि ऊपर दिए गए उदाहरणों में दिखाया गया है, वे क्रॉस-लाइब्रेरी/संस्करण संगतता के लिए बहुत कुछ करते हैं ...

हालांकि, रेगेक्स/स्ट्रिंग-पैटर्न प्रकारों के पास उस समस्या में नहीं पड़ने का एक अच्छा मौका है (उम्मीद है, मानकीकरण और समझदार पुस्तकालय लेखकों के लिए धन्यवाद)।

संपादित करें

थ्रेड में एक सामान्य बात यह है कि ये रेगेक्स टेस्ट कोड को मान्य करने में मदद करेंगे, क्योंकि उत्पादन परिदृश्यों में भले ही कोड हार्डकोडेड लिटरल्स के बजाय रनटाइम-प्रदत्त स्ट्रिंग्स के विरुद्ध चल रहा हो, फिर भी आप कुछ सत्यापन चाहते हैं कि आपके टेस्ट स्ट्रिंग्स " सही"। यह इसके बजाय नाममात्र/टैग/ब्रांडेड स्ट्रिंग्स के लिए एक तर्क प्रतीत होता है, हालांकि, चूंकि आप किसी भी तरह से सत्यापन फ़ंक्शन लिख रहे होंगे, और परीक्षणों का लाभ यह है कि आप जानते हैं कि वे पूरी तरह से चलते हैं (इस प्रकार परीक्षण इनपुट में कोई त्रुटि होगी विकास चक्र के आरंभ में ध्वजांकित किया जाना चाहिए)।

आह... मुझे यह लिखने से पहले सब कुछ पढ़ लेना चाहिए था...

वैसे भी, मेरे पास कुछ उदाहरण हैं, जहां स्ट्रिंग-पैटर्न प्रकार उपयोगी होते हैं।

HTTP मार्ग घोषणा पुस्तकालय

इस लिबरी के साथ, आप HTTP रूट डिक्लेरेशन ऑब्जेक्ट बना सकते हैं। यह घोषणा क्लाइंट और सर्वर दोनों द्वारा उपयोग की जाती है।

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

.append() लिए ये बाधाएं हैं,

• केवल स्ट्रिंग अक्षर (इस समय इसे लागू नहीं किया जा सकता है, लेकिन यदि आप गैर-शाब्दिक का उपयोग करते हैं, तो मार्ग घोषणा निर्माता कचरा बन जाता है)
• अग्रणी फ़ॉरवर्ड स्लैश से प्रारंभ होना चाहिए ( / )
• अनुगामी फ़ॉरवर्ड स्लैश के साथ समाप्त नहीं होना चाहिए ( / )
• कॉनलन वर्ण नहीं होना चाहिए ( : ); यह मापदंडों के लिए आरक्षित है
• लगातार दो या अधिक, फ़ॉरवर्ड स्लैश शामिल नहीं होने चाहिए ( // )

अभी, मेरे पास इनके लिए केवल रन-टाइम चेक हैं, जो त्रुटियों को फेंक देते हैं। मैं चाहूंगा कि डाउनस्ट्रीम उपभोक्ताओं को कुछ Github README या JSDoc टिप्पणी को पढ़ने की आवश्यकता के बिना इन बाधाओं का पालन करना पड़े। बस पथ लिखें और लाल रंग की टेढ़ी-मेढ़ी रेखाएं देखें।

अन्य सामान

मेरे पास हेक्साडेसिमल स्ट्रिंग्स, अल्फ़ान्यूमेरिक स्ट्रिंग्स के लिए रेगेक्स भी हैं।

मेरे पास यह भी है,

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

टीएल; डीआर (कृपया इसे पढ़ें, हालांकि, मैंने इसमें बहुत प्रयास किया है: रोना:)

• स्ट्रिंग-पैटर्न प्रकार नाममात्र/संरचनात्मक टैग प्रकारों की तुलना में अधिक एर्गोनोमिक हैं
  
  
  
  • कम बॉयलरप्लेट
  
  
• स्ट्रिंग-पैटर्न प्रकारों की सांकेतिक/संरचनात्मक टैग प्रकारों की तुलना में टॉवर ऑफ़ बैबेल स्थिति बनने की संभावना कम होती है
  
  
  
  • विशेष रूप से रेगेक्स उपप्रकार जांच के साथ
  
  
• स्ट्रिंग-पैटर्न प्रकार string प्रकार के बड़े परिमित/अनंत उपसमुच्चय को परिभाषित करने का सबसे स्वाभाविक तरीका है
  
  
  
  • इस सुविधा को पेश करने से लोग अपने पुस्तकालयों के लिए मान्य स्ट्रिंग प्रारूपों के बारे में अधिक बारीकी से सोच सकते हैं!
  
  
• स्ट्रिंग-पैटर्न प्रकार कुछ पुस्तकालयों के लिए मजबूत संकलन-समय सुरक्षा सक्षम करते हैं (मुझे आपके पास व्यापकता पर वापस आने दें ... भाग जाता है )
  
  
  
  • RegExp कंस्ट्रक्टर, हेक्स/अल्फ़ान्यूमेरिक स्ट्रिंग्स, रूट पाथ डिक्लेरेशन, डेटाबेस के लिए स्ट्रिंग आइडेंटिफ़ायर आदि।
  
  

आपके रेगेक्स इतने खराब क्यों हैं?

दूसरों द्वारा लाए गए उपयोग के मामलों का एक समूह मौजूदा पुस्तकालयों में फिट होने के लिए स्ट्रिंग-पैटर्न प्रकार पेश करना चाहता था; और यह TS टीम को आश्वस्त करने वाला प्रतीत नहीं होता है।

कई बार, मुझे ऐसा लगता है कि ये मौजूदा पुस्तकालय अपने इनपुट को मान्य करने के लिए रेगेक्स का इतना उपयोग नहीं करते हैं। या, वे एक साधारण सत्यापन करने के लिए रेगेक्स का उपयोग करते हैं। फिर, वे वास्तविक सत्यापन करने के लिए अधिक जटिल पार्सर का उपयोग करते हैं।

लेकिन यह स्ट्रिंग-पैटर्न प्रकारों के लिए एक वास्तविक वैध उपयोग केस है!

स्ट्रिंग-पैटर्न प्रकार मान्य स्ट्रिंग मानों के सुपरसेट को मान्य करने के लिए

बेशक, एक स्ट्रिंग है के साथ शुरू होता है / , साथ अंत नहीं है / , लगातार शामिल नहीं है / , और शामिल नहीं है : पारित करेंगे " HTTP पथ रेगेक्स"। लेकिन इसका मतलब सिर्फ इतना है कि इस रेगेक्स को पास करने वाले मानों का सेट मान्य HTTP पथों का सुपरसेट है।

इसके अलावा, हमारे पास एक वास्तविक यूआरएल पथ पार्सर है जो जांचता है कि ? का उपयोग नहीं किया गया है, # का उपयोग नहीं किया गया है, कुछ वर्ण बच निकले हैं, आदि।

लेकिन इस सरल स्ट्रिंग-पैटर्न प्रकार के साथ, हमने पहले से ही आम समस्याओं के एक बड़े वर्ग को समाप्त कर दिया है जो पुस्तकालय के एक उपयोगकर्ता का सामना कर सकता है! और हमने इसे संकलन-समय के दौरान भी समाप्त कर दिया!

ऐसा अक्सर नहीं होता है कि कोई उपयोगकर्ता अपने HTTP पथों में ? का उपयोग करेगा, क्योंकि अधिकांश को यह जानने के लिए पर्याप्त अनुभव है कि ? एक क्वेरी स्ट्रिंग की शुरुआत है।

मुझे अभी एहसास हुआ कि आप पहले से ही इस उपयोग के मामले के बारे में जानते हैं।

यह धागा उपयोग के मामलों की एक विस्तृत विविधता का तात्पर्य है; ठोस उदाहरण अधिक दुर्लभ रहे हैं। परेशानी की बात यह है कि इनमें से कई उदाहरण पूर्ण नहीं लगते हैं - वे एक RegExp का उपयोग करते हैं जो मान्य इनपुट को अस्वीकार कर देगा।

तो, निश्चित रूप से, प्रस्तावित बहुत से रेगेक्स "पूर्ण" नहीं हैं।
लेकिन जब तक वे मान्य इनपुट को अस्वीकार नहीं करते, यह ठीक होना चाहिए, है ना?

यह ठीक है अगर वे अमान्य इनपुट की अनुमति देते हैं, है ना?
चूंकि रन-टाइम के दौरान हमारे पास "वास्तविक" पार्सर पूर्ण सत्यापन हो सकता है।
और एक कंपाइल-टाइम चेक डाउनस्ट्रीम उपयोगकर्ताओं के लिए उत्पादकता में वृद्धि के लिए बहुत सी सामान्य समस्याओं को समाप्त कर सकता है।

वे उदाहरण जो मान्य इनपुट को अस्वीकार करते हैं, उन्हें संशोधित करना काफी आसान होना चाहिए, ताकि वे मान्य इनपुट को अस्वीकार न करें, लेकिन अमान्य इनपुट की अनुमति दें।

स्ट्रिंग-पैटर्न प्रकार और चौराहे

वैसे भी, स्ट्रिंग-पैटर्न प्रकारों पर चौराहे के प्रकार सुपर डुपर उपयोगी होंगे!

मेरा .append() उदाहरण इस प्रकार लिखा जा सकता है,

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

not PatternOf</\/\//> भी हो सकता है,
PatternOf</^((([/])(?!\3))|[^/])+$/> लेकिन यह बहुत अधिक जटिल है

व्यापक प्रदर्शनों के लिए @AnyhowStep धन्यवाद। मुझे इतना पढ़ने के लिए मजबूर करने के लिए मैं आपकी आलोचना करना चाहता था, लेकिन यह बहुत मददगार साबित हुआ!

मैं अक्सर स्ट्रिंग मापदंडों से भरे अपने आंतरिक एपिस को टाइप करने के लिए संघर्ष करता हूं, और मैं अनिवार्य रूप से बहुत सारी शर्तों के साथ समाप्त होता हूं जो रन-टाइम पर फेंक देते हैं। अनिवार्य रूप से, मेरे उपभोक्ताओं को इन पैटर्न जांचों को डुप्लिकेट करने की आवश्यकता है, क्योंकि वे अपवाद नहीं चाहते हैं, वे विफलता को संभालने का एक विशेष तरीका चाहते हैं।

// 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 और स्ट्रिंग शाब्दिक प्रकारों को फैलाते समय अनुमान टाइप करें।

भविष्य की अटकलें:

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;

उपयोग के कुछ मामलों के लिए उल्लेख किया गया है कि रेगेक्स के केवल एक छोटे से सबसेट की आवश्यकता होगी, जैसे उपसर्ग मिलान।

मैं अभी भी अपने प्रस्ताव पर कायम स्टार-मुक्त भाषाओं का बहुत छोटा सुपरसेट आप अभी भी उचित रूप से सबसेट और समानता के लिए कुशलतापूर्वक जांच कर सकते हैं। और अब तक, मैंने मनमाने नियमित अभिव्यक्तियों के प्रदर्शन पहलू को संबोधित करने का कोई अन्य प्रस्ताव प्रयास नहीं देखा है, टीएस टीम की सबसे बड़ी चिंता है।

जैसा कि नाम से पता चलता है, स्टार मुक्त भाषाओं के साथ समस्या यह है कि आप सितारों का उपयोग नहीं कर सकते हैं, जिससे यूआरएल जैसी चीजों को मान्य करना मुश्किल हो जाता है। इसके अलावा, ज्यादातर लोग शायद सितारों को चाहते हैं, और उनका अनुकरण करने के लिए केवल एक मनमानी संख्या में दोहराए जाने वाले अनुक्रमों का उपयोग करें, जिससे सबसेट की जांच करना मुश्किल हो जाएगा।

और अधिकांश सामान्य डीएफए प्रतिनिधित्व योग्य रेगेक्स का प्रदर्शन उतना बुरा नहीं है, और उप/सुपरसेट के लिए इन्हें जांचना संभव है।

हालांकि, आप अभी भी * प्राप्त कर सकते हैं।

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

@TijmenW मेरे प्रस्ताव को थोड़ा और करीब से पढ़ें - वहाँ कुछ छिपे हुए तर्क हैं, और कुछ छोटी विशेषताएं हैं जो इसे वास्तव में व्यावहारिक बनाती हैं। यह सीधे तौर पर स्टार-मुक्त व्याकरण निर्दिष्ट करने तक ही सीमित नहीं है, बल्कि मेरे अर्ध-उन्नत उपयोग के मामले के लिए व्यावहारिक रूप से उपयोगी बनाने के लिए पर्याप्त के साथ विस्तारित एक छोटा सुपरसेट है। विशेष रूप से, आप कर सकते हैं starof ('a' | 'b' | ...) अलग-अलग पात्रों के लिए और आप उपयोग कर सकते हैं string के बराबर starof UnionOfAllCodePoints (यह अब सिद्धांत में एक आदिम बनाने प्रभाव में)।

साथ ही, यह जांचना कि क्या कोई नियमित भाषा किसी अन्य नियमित भाषा से मेल खाने वाले सबसेट से मेल खाती है, एनपी-पूर्ण है और सामान्य सबग्राफ आइसोमोर्फिज्म समस्या के बराबर starof को सीमित करने का प्रयास क्यों किया।

TODO: कृपया वास्तविक पुस्तकालय कार्यों की पहचान करके हमारी सहायता करें जो RegExp प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं।

इसे नमक के दाने के साथ लें, क्योंकि यह एक बिल्कुल नई लाइब्रेरी है, लेकिन https://github.com/ostror/ts-json-validator जैसी किसी भी लाइब्रेरी को रेगेक्स प्रकार जैसी किसी चीज़ के साथ और अधिक उपयोगी बनाया जाएगा।

पुस्तकालय का लक्ष्य टाइपप्रति प्रकार/JSON स्कीमा जोड़े <T, s> उत्पन्न करना है जैसे कि

1. कोई भी प्रकार जिसे s मान्य कर सकता है, T को असाइन किया जा सकता है
2. कुछ प्रकार के रूप में संभव के रूप में करने के लिए आबंटित हैं कि T जब खिलाफ चलाए सत्यापन असफल s ।

एक रेगेक्स प्रकार मान्य प्रकार को कम से कम निम्नलिखित कीवर्ड के बारे में सख्त होने की अनुमति देकर (2) की कठोरता में सुधार करेगा:

• format
• patternProperties
• propertyNames

TODO: कृपया वास्तविक पुस्तकालय कार्यों की पहचान करके हमारी सहायता करें जो RegExp प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं।

सभी एक्सेल इंटरफ़ेस पुस्तकालय प्रकार सत्यापन का उपयोग A1 या A5:B7 ।

संपत्ति कुंजी/रेगेक्स स्ट्रिंग इंडेक्सर्स

कुछ पुस्तकालय संपत्ति के नाम के अनुसार वस्तुओं का इलाज करते हैं। उदाहरण के लिए, रिएक्ट में हम किसी भी प्रोप पर टाइप लागू करना चाहते हैं जिसका नाम aria- शुरू होता है:

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

यह प्रभावी रूप से एक ऑर्थोगोनल अवधारणा है (हम Regex गुण कुंजियों को जोड़े बिना Regex प्रकार जोड़ सकते हैं, और इसके विपरीत)।

मुझे पता है कि यह यहां होने वाली हर चीज के लिए थोड़ा सा ऑर्थोगोनल है लेकिन वेस्ली ने सोचा कि आप हमारे इनपुट का उपयोग कर सकते हैं। यह कई कारणों से फैब्रिक में आता रहता है। एक घटक पुस्तकालय के रूप में, हम एक घटक प्रॉप्स इंटरफ़ेस को ऊंचा करने में सक्षम होना चाहते हैं जो टाइपस्क्रिप्ट द्वारा अनुमत रिएक्ट घटक इंटरफ़ेस को सटीक रूप से दर्शाता है, जिसमें data- और aria- विशेषताएँ शामिल हैं। इसके बिना हम अपने उपभोक्ताओं को इन विशेषताओं के लिए उपयोग करने के

अगर कुछ है तो हम मदद कर सकते हैं, कृपया मुझे बताएं! मैं

टीएस खेल का मैदान :

import * as React from 'react';

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

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

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

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

TODO: कृपया वास्तविक पुस्तकालय कार्यों की पहचान करके हमारी सहायता करें जो RegExp प्रकारों और आपके द्वारा उपयोग की जाने वाली वास्तविक अभिव्यक्ति से लाभान्वित हो सकते हैं

क्रॉन जॉब्स। (बहुत आश्चर्य हुआ कि इसका उल्लेख नहीं किया गया था)

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

बस मेरे दो सेंट यहां फेंक रहे हैं - मैं एक रिएक्ट प्रोजेक्ट पर काम कर रहा हूं, जहां हम एक प्रोप को मान्य करना चाहते हैं जिसका उपयोग HTML id विशेषता के रूप में किया जाएगा। इसका मतलब है कि इसे निम्नलिखित नियमों को पूरा करना होगा या अप्रत्याशित व्यवहार होगा:

1. कम से कम एक चरित्र हो
2. रिक्त स्थान नहीं है

दूसरे शब्दों में:

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

एक अन्य उदाहरण: '<namespace>/<name>[@<version>]' . प्रारूप में अपेक्षित स्ट्रिंग वाले अभयारण्य-प्रकार-पहचानकर्ता

केस का उपयोग करें: स्ट्रिंग-टाइप किए गए DOM API जैसे Navigator.registerProtocolHandler() ।

एमडीएन का हवाला देते हुए:

सुरक्षा कारणों से, 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 यह सैद्धांतिक रूप से सिर्फ एक सबसेट है, जहां यह विशेष रूप से स्ट्रिंग प्रकारों को परिष्कृत कर रहा है। (संख्यात्मक प्रकारों की अपनी चिंताएँ हैं, निश्चित रूप से।)

उपयोग के कुछ मामलों के लिए उल्लेख किया गया है कि रेगेक्स के केवल एक छोटे से सबसेट की आवश्यकता होगी, जैसे उपसर्ग मिलान।

मैं अभी भी अपने प्रस्ताव पर कायम स्टार-मुक्त भाषाओं का बहुत छोटा सुपरसेट आप अभी भी उचित रूप से सबसेट और समानता के लिए कुशलतापूर्वक जांच कर सकते हैं। और अब तक, मैंने मनमाने नियमित अभिव्यक्तियों के प्रदर्शन पहलू को संबोधित करने का कोई अन्य प्रस्ताव प्रयास नहीं देखा है, टीएस टीम की सबसे बड़ी चिंता है।

इस टिप्पणी में,
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

(बेशक, जेएस रेगुलर एक्सप्रेशन गैर-नियमित हैं)

@AnyhowStep जो काम कर सकता है - मैं केवल starof प्रतिबंध हटा दूंगा और तदनुसार उस प्रतिबंध को बदल चाहता हूं, क्योंकि गणित थोड़ा सा सार है और यह स्पष्ट नहीं है कि यह अभ्यास में कैसे लागू होगा (उन प्रकार का उपयोग करने वाले सभी लोग औपचारिक भाषाओं में अच्छी तरह से वाकिफ नहीं हैं)।

साथ ही, अलग से, मैं उस तरह की चीज़ को मॉडल करने के लिए एक ऑपरेटर के रूप में starof बेहतर विकल्प को बहुत दृढ़ता से पसंद करूंगा।

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

मैं उत्सुक हूं: क्या नियमित अभिव्यक्तियों को शामिल करना/रोकना तय करना संभव है? विकिपीडिया के अनुसार , यह निर्णायक है। हालांकि, क्या यह जेएस में नियमित अभिव्यक्तियों के लिए भी जिम्मेदार है? मुझे लगता है कि उनके पास मानक आरई (जैसे बैकरेफरेंस) की तुलना में अधिक सुविधाएं हैं। यदि यह निर्णायक है, तो क्या यह कम्प्यूटेशनल रूप से संभव है?
यह इस सुविधा को प्रभावित करेगा (संकीर्ण):

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

यथार्थवादी होने के लिए @nikeee Decidable पर्याप्त नहीं है। इस पैमाने पर द्विघात समय भी आमतौर पर बहुत धीमा होता है। टीएस नहीं, लेकिन मेरे पास इसी तरह के मुद्दों पर कुछ पृष्ठभूमि है।

बैकरेफरेंस के सामने, मुझे संदेह है कि यह अभी भी निर्णायक है, लेकिन संभावित रूप से घातीय यदि बदतर नहीं है। हालांकि, सिर्फ एक शिक्षित अनुमान।

इसे स्पष्ट करने के लिए धन्यवाद!

इस पैमाने पर द्विघात समय भी आमतौर पर बहुत धीमा होता है।

यही कारण है कि मैंने यह भी पूछा कि क्या यह कम्प्यूटेशनल रूप से व्यवहार्य है, इसलिए मुझे लगता है कि यह नहीं है।

अगर समानता पर भी यही बात लागू होती है, तो क्या इसका मतलब यह नहीं है कि इस विशेषता की लगभग हर संपत्ति संभव नहीं है? अगर मैं गलत हूं तो मुझे सुधारो, लेकिन ऐसा लगता है कि केवल एक चीज जो बची है वह है सदस्यता। मुझे नहीं लगता कि यह अकेले उपयोगी होगा।

@nikeee यह ध्यान में रखने योग्य है कि इस पैटर्न की तुलना सचमुच हर प्रकार की प्रत्येक संपत्ति के विरुद्ध की जाएगी । और रेगेक्सपी गुणों वाले प्रकारों के लिए, आपको यह गणना करनी होगी कि क्या एक रेगेक्सपी एक अन्य रेगेक्सपी मैचों के सबसेट से मेल खाता है, जो अपने आप में एक जटिल जानवर है।

यह असंभव नहीं है, बस कठिन है , और यदि आप इसे व्यवहार्य बनाना चाहते हैं तो आपको प्रतिबंधात्मक होना होगा। (एक के लिए, JS regexps काम नहीं करेगा - वे न केवल पर्याप्त एक्स्टेंसिबल हैं, बल्कि बहुत लचीले भी हैं।)

संपादित करें: मैं इसे दोहराना चाहता हूं: मैं टीएस टीम में नहीं हूं, बस स्पष्ट करने के लिए। मेरे पास सीएस एल्गोरिदम डिज़ाइन में बस एक अच्छी पृष्ठभूमि है।

हम्म, तो हो सकता है कि आप केवल "सामान्य" RegEx के "सीमित" सबसेट का समर्थन कर सकें। उपयोग के मामलों को देखते हुए, रेगेक्स अब तक काफी सरल थे ... (रंग, फोन नंबर इत्यादि)

हम केवल एक उपसमुच्चय का समर्थन करने के लिए UX को कैसे डिज़ाइन कर सकते हैं? उपयोगकर्ता के लिए यह बहुत स्पष्ट नहीं हो सकता है कि रेगेक्स का फीचर एक्स काम करता है, लेकिन वाई नहीं करता है।

ठीक है ... इसे "रेगेक्स" न कहें - एक स्टार्टर के लिए। शायद सिर्फ "पैटर्न मिलान" या तो: देखें_नो_ बुराई:। लेकिन हाँ, शायद कोई आसान काम नहीं है...

इस तरह एक गैर-रेगेक्स सिंटैक्स के बारे में क्या:

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}`

(यह मानता है कि कार्यान्वयन संघ प्रकारों का उपयोग करेगा। यह एक अलग/अधिक जटिल कार्यान्वयन के साथ काम कर सकता है)

अस्वीकरण: मैं टीएस टीम का हिस्सा नहीं हूं और मैं टीएस पर काम नहीं कर रहा हूं। बस मेरा 2c.

@rozzzly @nikeee कमोबेश मेरे प्रस्ताव का सार है , बस कुछ छोटी विशेषताएं गायब हैं। मैं नियमित भाषाओं (औपचारिक भाषा अवधारणा) के एक बड़े उपसमुच्चय पर आधारित हूं, रेगेक्सपी अक्षर के अर्थ में नियमित अभिव्यक्ति नहीं है, इसलिए यह उन लोगों की तुलना में बहुत कम शक्तिशाली है लेकिन काम पूरा करने के लिए पर्याप्त शक्तिशाली है।

मुझे लगता है कि यह दृष्टिकोण अधिक उपयोगकर्ता के अनुकूल होगा। हालाँकि, यह प्रकारों पर अंकगणितीय संक्रियाओं के समान प्रतीत होता है।

मैथ का कहना है कि यह सत्यापित करना कि एक प्रकार दूसरे का उप प्रकार है या नहीं, यह जांचने के बराबर है कि कोई स्ट्रिंग किसी औपचारिक भाषा में निहित है या नहीं।

यदि आप टीएलडी/ सार्वजनिक प्रत्यय वैधता की जांच भी करते हैं तो डोमेन सत्यापन विशेष रूप से एक बहुत ही जटिल चीज है। RFC के अनुसार स्वयं जेनेरिक डोमेन /[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)+/ + जितने सरल हैं, अधिकतम 255 वर्ण हैं, लेकिन यहां तक ​​​​कि यह टाइप करने के लिए बहुत जटिल है जब तक कि आप पूर्ण नियमित व्याकरण के लिए नहीं जाते हैं जैसा कि उपरोक्त regexp प्रदर्शित करता है। आप @rozzly या मेरे प्रस्ताव से केवल स्ट्रिंग्स का उपयोग करके प्रोग्रामेटिक रूप से बहुत सीधे प्रकार (मैं इसे पाठक के लिए एक अभ्यास के रूप में छोड़ दूंगा) उत्पन्न कर सकता हूं, लेकिन अंतिम परिणाम अभी भी जटिल है।

@isiahmeadows

कमोबेश यही मेरे प्रस्ताव का सार है , बस कुछ छोटी विशेषताएं गायब हैं।

पिछली बार जब मैंने इस पूरे सूत्र को पढ़ा था तो एक साल से अधिक समय हो गया था। मैं अपने ब्रेक पर था और एक अधिसूचना देखी, @rugk की टिप्पणी _ "अच्छी तरह से ... इसे "रेगेक्स" न कहें - स्टार्टर के लिए "_ जो मुझे सोच रहा था ... मुझे नहीं पता था कि किसी ने पहले से ही किया था अनिवार्य रूप से समान _(/ बहुत समान) _ विचार के लिए काफी अधिक विस्तृत प्रस्ताव पेश किया।

... यहां तक ​​​​कि यह टाइप करने के लिए बहुत जटिल है जब तक कि आप पूर्ण नियमित व्याकरण के लिए नहीं जाते हैं जैसा कि उपरोक्त रेगेक्सपी प्रदर्शित करता है। आप @rozzly या मेरे प्रस्ताव से केवल स्ट्रिंग्स का उपयोग करके प्रोग्रामेटिक रूप से बहुत सीधे प्रकार (मैं इसे पाठक के लिए एक अभ्यास के रूप में छोड़ दूंगा) उत्पन्न कर सकता हूं, लेकिन अंतिम परिणाम अभी भी जटिल है।

मेरे दिमाग में, सीमित पैटर्न मिलान के लिए कुछ सुविधा जैसे मैंने सुझाव दिया है कि अनुमति बहुत ही सरल और _आवश्यक रूप से नहीं-कठोर सख्त_ टाइपिंग के लिए बेहद उपयोगी होगी। मैंने जो उदाहरण दिया है वह सटीक नहीं है, और संकलक को उड़ा नहीं देगा।

लेकिन जैसा कि @nikeeee और आप दोनों बताते हैं कि इसे खतरनाक चरम पर ले जाया जा सकता है। केवल यूनियनों का समर्थन करने वाला सबसे भोला कार्यान्वयन मानते हुए। कोई व्यक्ति @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)'

तो हाँ.. वहाँ कुछ मुद्दे हैं

@rozzly क्या उस प्रकार को TupleWithLengthBeteen1And64<Charset> से अलग (व्यवहार्यता के मामले में) बनाता है?
शिकायतकर्ता को हर प्रकार को सामान्यीकृत रूप में विस्तारित करने के लिए मजबूर नहीं किया जाता है, अगर ऐसा होता है तो यह काफी सामान्य प्रकारों पर जल्दी से विस्फोट हो जाएगा।
यह नहीं कह रहा कि मुझे लगता है कि यह मुद्दा इस समय टाइपस्क्रिप्ट में समझ में आता है, अगर "3 और 1024 के बीच पूर्णांक" (संदेश बफर आवंटन लंबाई सोचें) को दायरे से बाहर माना जाता है।

@simonbuchan कम से कम उपसर्ग और प्रत्यय प्रकार मौजूद होने की आवश्यकता है, अगर और कुछ नहीं। कई डोम पुस्तकालयों और ढांचे के लिए यह स्वयं आवश्यक है।

मुझे पता है कि इसे पीट-पीट कर मार डाला गया है और कुछ अच्छे प्रस्ताव पहले ही दिए जा चुके हैं। लेकिन मैं सिर्फ अतिरिक्त सामान जोड़ना चाहता था जो कुछ को हल्का दिलचस्प लग सकता है।

बैकरेफरेंस के सामने, मुझे संदेह है कि यह अभी भी निर्णायक है, लेकिन संभावित रूप से घातीय यदि बदतर नहीं है। हालांकि, सिर्फ एक शिक्षित अनुमान।

बैक रेफरेंस एक रेगेक्सपी को संदर्भ-संवेदनशील व्याकरण का वर्णन कर सकता है, जो संदर्भ-मुक्त व्याकरण का एक सुपरसेट है। और CFG के लिए भाषा समानता अनिर्णीत है। तो यह सीएसजी के लिए और भी बदतर है, जो रैखिक-बाध्य ऑटोमेटन के बराबर हैं।

केवल सभी नियमित अभिव्यक्तियों को मानते हुए जिन्हें डीएफए में परिवर्तित किया जा सकता है, एक रेगेक्सपी (कॉनैट, यूनियन, स्टार, चौराहे, पूरक इत्यादि) में उपयोग किया जाता है, एक रेगेक्सपी को एनएफए में परिवर्तित करना ओ (एन) है, दो का उत्पाद प्राप्त करना एनएफए ओ (एम * एन) है, फिर स्वीकार्य राज्यों के परिणामी ग्राफ को पार करना ओ (एम * एन) है। तो, दो नियमित रेगेक्सप्स की भाषा समानता/सबसेट की जांच भी ओ (एम * एन) है।

समस्या यह है कि यहाँ वर्णमाला वास्तव में बड़ी है। डीएफए/एनएफए/नियमित अभिव्यक्तियों के बारे में बात करते समय पाठ्यपुस्तकें खुद को 1-5 आकार के अक्षरों तक सीमित रखती हैं। लेकिन जेएस रेगेक्सप्स के साथ, हमारे पास सभी यूनिकोड हमारे वर्णमाला के रूप में हैं। दी, विरल सरणियों और अन्य चतुर हैक और समानता / सबसेट परीक्षण के लिए अनुकूलन का उपयोग करके संक्रमण कार्यों का प्रतिनिधित्व करने के कुशल तरीके हो सकते हैं ...

मुझे विश्वास है कि नियमित-से-नियमित असाइनमेंट के लिए कुछ हद तक कुशलता से टाइप करना संभव है।

फिर, सभी गैर-नियमित असाइनमेंट को केवल स्पष्ट प्रकार के दावे की आवश्यकता हो सकती है।

मैंने हाल ही में एक छोटे से परिमित automaton प्रोजेक्ट पर काम किया है, इसलिए मेरे दिमाग में जानकारी अभी भी ताज़ा है =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 backreferences एकमात्र संदर्भ-संवेदनशील उत्पादन हैं (और उस पर एक काफी सरल और सीमित - केवल 9 समूहों तक ही संदर्भित किया जा सकता है), और शेष रेगेक्सपी व्याकरण नियमित है, इसलिए मुझे संदेह है यह निर्णायक है। लेकिन परवाह किए बिना, मुझे लगता है कि हम सहमत हो सकते हैं कि यह शब्द के किसी भी अर्थ में व्यावहारिक नहीं है। मैं

संपादित करें: सटीकता

मैंने इस टिप्पणी की पुष्टि @rozzly से TS 4.1.0 रात के साथ काम करती है!

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

const success: Url = 'https://example.com';
const fail: Url = 'example.com';
const domain: Domain = 'example.com';

इसे खेल के मैदान में आज़माएं और देखें कि fail में संकलन समय त्रुटि है

अद्यतन : इस सुविधा के साथ थोड़ा खेलने के बाद, यह कई उपयोग के मामलों को कवर नहीं करेगा। उदाहरण के लिए, यह हेक्स रंग स्ट्रिंग के लिए काम नहीं करता है।

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

मैंने इस टिप्पणी की पुष्टि @rozzly से TS 4.1.0 रात के साथ काम करती है!

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

const success: Url = 'https://example.com';
const fail: Url = 'example.com';
const domain: Domain = 'example.com';

इसे खेल के मैदान में आज़माएं और देखें कि fail में संकलन समय त्रुटि है

यह डेटा-या एरिया-समस्या को हल करेगा जो हम में से अधिकांश यूएक्स पुस्तकालयों में सामना करते हैं यदि इसे इंडेक्स पर लागू किया जा सकता है।

मूल रूप से यह लेकिन स्पष्ट रूप से यह काम नहीं करता है क्योंकि TS केवल स्ट्रिंग की अनुमति देता है | संख्या। चूंकि यह अनिवार्य रूप से एक स्ट्रिंग है, क्या इसे सक्षम किया जा सकता है?
https://www.typescriptlang.org/play?target=99&ts=4.1.0-dev.20201001#code/LAKALgngDgpgBAEQIZicgzgCzgXjgAwBIBvAcgBMUkBaUgXxPTACcBLAOwHM78BuUDmBjMAZkgDG8AJIAVGEzjFQcFXADalVBkwAFZgHsoALmRakWALpGmbLvxB1QocfvYL0AV3GT06I3Fl5MFxFCipqISZSI1JIsHpeIA

_Update_: इस फीचर के साथ थोड़ा खेलने के बाद, यह कई उपयोग मामलों को कवर नहीं करेगा। उदाहरण के लिए, यह हेक्स रंग स्ट्रिंग के लिए काम नहीं करता है।

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 में कुछ अविश्वसनीय पोस्ट किए जो वैसे भी कागज पर अच्छे लगते हैं।

मुझे यह इसलिए मिला क्योंकि मैं यह सुनिश्चित करना चाहता था कि मेरे फ़ंक्शन में पास की गई वस्तु की चाबियां वैध सीएसएस वर्ग के नाम हों। मैं आसानी से रनटाइम पर जांच कर सकता हूं ... लेकिन मेरे लिए यह इतना स्पष्ट लगता है कि टाइपस्क्रिप्ट संकलन समय पर ऐसा करने में सक्षम होना चाहिए, खासकर उन परिस्थितियों में जहां मैं केवल हार्ड-कोडिंग ऑब्जेक्ट अक्षर हूं और टाइपस्क्रिप्ट को यह पता लगाना नहीं चाहिए कि क्या MyUnionExtendedExoticप्रकार कुछ मनमानी रेगेक्स टाइप को संतुष्ट करता है।

हो सकता है कि एक दिन मैं और अधिक उत्पादक योगदान देने के लिए पर्याप्त जानकार हो जाऊं: /

मैंने इस टिप्पणी की पुष्टि @rozzly से TS 4.1.0 रात के साथ काम करती है!

वाह वाह। मैंने ईमानदारी से इसे लागू होते देखने की उम्मीद नहीं की थी, कम से कम जल्द ही नहीं।

@chadlavi-केसबुक

जारी नोटों में इस सीमा का कुछ संदर्भ था। यह सभी संभावित वैध संयोजनों की एक सूची बनाता है, इस मामले में यह 16,777,216 (यानी, 16 ^ 6) सदस्यों के साथ एक संघ बनाएगा।

मैं यह देखने के लिए उत्सुक हूं कि समस्या प्रदर्शन के अनुसार संघ कितना बड़ा हो सकता है। @styfle का उदाहरण दिखाता है कि उस छत को हिट करना कितना आसान है। स्पष्ट रूप से जटिल प्रकार बनाम प्रदर्शन की उपयोगिता के कुछ हद तक घटते रिटर्न होने जा रहे हैं।

@thehappycheese

मैं यह सुनिश्चित करना चाहता था कि मेरे फ़ंक्शन में पास की गई वस्तु की चाबियां वैध सीएसएस वर्ग के नाम हों

मुझे यह कहते हुए पूरा विश्वास है कि वर्तमान कार्यान्वयन के साथ यह संभव नहीं है। यदि क्वांटिफायर और श्रेणियों के लिए समर्थन था तो आपको शायद बीईएम शैली वर्ग के नामों के लिए सत्यापन मिल जाएगा। इसके लिए मानक जेएस रेगेक्स _too_ भयानक नहीं है:
^\.[a-z]([a-z0-9-]+)?(__([a-z0-9]+-?)+)?(--([a-z0-9]+-?)+){0,2}$
आप एंकरों को भी छोड़ देंगे क्योंकि जैसा कि कार्यान्वयन खड़ा है, यह या तो एक एंड-टू-एंड मैच है या कुछ भी नहीं है इसलिए ^ और $ निहित हैं। अब यह एक वैध सीएसएस चयनकर्ता के संकीर्ण सबसेट के लिए तुलनात्मक रूप से सरल रेगेक्स है। उदाहरण के लिए: ಠ_ಠ एक मान्य वर्ग नाम है। मैं मजाक नहीं कर रहा हु।

मुझे क्षमा करें। मुझे यह करना था।

मैंने टाइपस्क्रिप्ट में नियमित भाषाओं को लागू किया।

• खेल का मैदान #1 ,

• खेल का मैदान #2 , लंबाई 6 . की हेक्स स्ट्रिंग

अधिक सटीक रूप से, मैंने TS 4.1 . का उपयोग करके एक साधारण नियतात्मक परिमित ऑटोमेटन लागू किया

मेरा मतलब है, हम पहले से ही टीएस में ट्यूरिंग मशीनों को लागू कर सकते हैं। तो, इसकी तुलना में डीएफए और पीडीए "आसान" हैं।

और टेम्पलेट तार इसे और अधिक उपयोगी बनाते हैं।

मूल प्रकार वास्तव में सरल हैं और <30 LOC में फिट हैं,

type Head<StrT extends string> = StrT extends `${infer HeadT}${string}` ? HeadT : never;

type Tail<StrT extends string> = StrT extends `${string}${infer TailT}` ? TailT : never;

interface Dfa {
    startState : string,
    acceptStates : string,
    transitions : Record<string, Record<string, string>>,
}

type AcceptsImpl<
    DfaT extends Dfa,
    StateT extends string,
    InputT extends string
> =
    InputT extends "" ?
    (StateT extends DfaT["acceptStates"] ? true : false) :
    AcceptsImpl<
        DfaT,
        DfaT["transitions"][StateT][Head<InputT>],
        Tail<InputT>
    >;

type Accepts<DfaT extends Dfa, InputT extends string> = AcceptsImpl<DfaT, DfaT["startState"], InputT>;

यह उन ऑटोमेटन को निर्दिष्ट कर रहा है जो कठिन हिस्सा हैं।

लेकिन मुझे पूरा यकीन है कि कोई टाइपस्क्रिप्ट डीएफए ™ जनरेटर के लिए

मैं यह भी उजागर करना चाहूंगा कि "लंबाई 6 की हेक्स स्ट्रिंग" उदाहरण से पता चलता है कि आप फ़ंक्शन पैरामीटर केवल बदसूरत हैकरी का उपयोग करके रेगेक्स से मेल खाने वाले तारों को स्वीकार कर सकते हैं,

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

एक अंतिम उदाहरण, खेल का मैदान ; यह एक फ्लोटिंग पॉइंट स्ट्रिंग रेगेक्स है !

@AnyhowStep वैसे मैंने आपके डीएफए विचार का उपयोग एक साधारण रेगेक्स [abc]{4} को लागू करने के लिए किया है जिसका अर्थ है कि अक्षरों को किसी भी क्रम में लापता लेकिन बिल्कुल 4 की लंबाई (आआ, एबीसी, बीबीसीसी, आदि ...) के साथ।
खेल का मैदान

https://cyberzhg.github.io/toolbox/min_dfa?regex=ZCgoYmQqYiopKmMpKg==

https://github.com/CyberZHG/toolbox

अगर मेरे पास अधिक इच्छाशक्ति होती, तो मैं ऊपर की तरह कुछ पकड़ लेता और रेगेक्स को टीएस डीएफए ™ में बदलने के लिए इसका इस्तेमाल करता

ठीक है, मैंने अभी एक प्रोटोटाइप एक साथ फेंका है,

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

[संपादित करें] https://glitch.com/~efficcious-valley-repair <- यह अधिक जटिल रेगेक्स के लिए बेहतर आउटपुट देता है

[संपादित करें] ऐसा लगता है कि ग्लिच उन मुक्त परियोजनाओं को संग्रहित करेगा जो बहुत लंबे समय से निष्क्रिय हैं। तो, यहाँ फाइलों के साथ एक git रेपो है,
https://github.com/AnyhowStep/efficcious-valley-repair/tree/main/app

चरण 1, यहां अपने रेगेक्स में कुंजी,

चरण 2, कन्वर्ट पर क्लिक करें,

चरण 3, उत्पन्न TS खेल का मैदान URL पर क्लिक करें,

चरण 4, नीचे स्क्रॉल करें InLanguage_0 ,

चरण 5, इनपुट मानों के साथ खेलें,

रूपांतरण के भारी भारोत्तोलन के लिए, https://www.npmjs.com/package/regex2dfa के लेखक @kpdyer को

अगर किसी को कुछ अधिक शक्तिशाली चाहिए, तो यहां एक ट्यूरिंग मशीन है

खेल का मैदान

यह धागा पढ़ने में बहुत लंबा हो गया है और कई टिप्पणियों को या तो टेम्पलेट शाब्दिक प्रकारों द्वारा संबोधित किया जाता है या विषय से परे हैं। मैंने एक नया अंक #41160 इस बात की चर्चा के लिए बनाया है कि इस सुविधा द्वारा कौन से शेष उपयोग मामलों को सक्षम किया जा सकता है। यहां टाइप सिस्टम पार्सर्स पर चर्चा जारी रखने के लिए स्वतंत्र महसूस करें