Typescript: सुझाव: इंडेक्स सिग्नेचर में अपरिभाषित को शामिल करने का विकल्प

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

@mhegazy यह एक दिलचस्प विचार है। सरणी/वस्तु के लिए प्रकार के हस्ताक्षर को ओवरराइड करने के तरीके पर कोई मार्गदर्शन?

interface Array<T> में lib.d.ts । मैंने अन्य अनुक्रमण हस्ताक्षरों को खोजने के लिए regexp \[\w+: (string|number)\] द्वारा भी खोजा।

दिलचस्प है, इसलिए मैंने यह कोशिश की:

{
    // https://github.com/Microsoft/TypeScript/blob/1f92bacdc81e7ae6706ad8776121e1db986a8b27/lib/lib.d.ts#L1300
    declare global {
        interface Array<T> {
            [n: number]: T | undefined;
        }
    }

    const xs = [1,2,3]
    const x = xs[100]
    x // still number :-(
}

कोई विचार?

प्रतिलिपि lib.d.ts स्थानीय रूप से कहते हैं, lib.strict.d.ts , के लिए सूचकांक हस्ताक्षर बदल [n: number]: T | undefined; , अपने संकलन में फ़ाइल शामिल हैं। आपको इच्छित प्रभाव देखना चाहिए।

कूल, इसके लिए धन्यवाद।

यहां सुझाए गए फिक्स के साथ समस्या यह है कि इसे एक अलग lib फ़ाइल को फोर्क करने और बनाए रखने की आवश्यकता है।

मुझे आश्चर्य है कि क्या इस सुविधा की मांग बॉक्स से बाहर किसी प्रकार के विकल्प को वारंट करने के लिए पर्याप्त है।

एक तरफ ध्यान दें पर, यह दिलचस्प है कि के लिए प्रकार हस्ताक्षर get ES6 संग्रह पर विधि ( Map / Set ) रिटर्न T | undefined जब Array / Object अनुक्रमणिका हस्ताक्षर नहीं करते हैं।

यह एक सचेत निर्णय है। इस कोड के लिए त्रुटि होना बहुत कष्टप्रद होगा:

var a = [];
for (var i =0; i< a.length; i++) {
    a[i]+=1; // a[i] is possibly undefined
}

और प्रत्येक उपयोगकर्ता को ! का उपयोग करने के लिए कहना अनुचित होगा। या लिखने के लिए

var a = [];
for (var i =0; i< a.length; i++) {
    if (a[i]) {
        a[i]+=1; // a[i] is possibly undefined
    }
}

मानचित्र के लिए आम तौर पर ऐसा नहीं होता है।

इसी तरह आपके प्रकार के लिए, आप अपने सभी अनुक्रमणिका हस्ताक्षरों पर | undefined निर्दिष्ट कर सकते हैं, और आपको अपेक्षित व्यवहार मिलेगा। लेकिन Array यह उचित नहीं है। पुस्तकालय को फोर्क करने के लिए आपका स्वागत है और आपको जो भी परिवर्तन करने की आवश्यकता है, लेकिन इस बिंदु पर मानक पुस्तकालय में घोषणा को बदलने की हमारी कोई योजना नहीं है।

मुझे नहीं लगता कि किसी घोषणा के आकार को बदलने के लिए ध्वज जोड़ना कुछ ऐसा है जो हम करेंगे।

@mhegazy लेकिन छेद वाले सरणी के लिए a[i] वास्तव में संभवतः अपरिभाषित है:

let a: number[] = []
a[0] = 0
a[5] =0
for (let i = 0; i < a.length; i++) {
  console.log(a[i])
}

आउटपुट है:

undefined
undefined
undefined
undefined
0

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

अगर कोई अपने lib.d.ts को संशोधित करना चाहता है और अपने कोड में सभी डाउनस्ट्रीम ब्रेक को ठीक करना चाहता है और दिखाता है कि समग्र अंतर कैसा दिखता है, यह दिखाने के लिए कि इसमें कुछ मूल्य प्रस्ताव है, हम उस डेटा के लिए खुले हैं। वैकल्पिक रूप से यदि बहुत से लोग पोस्टफ़िक्स ! अधिक का उपयोग करने के लिए वास्तव में उत्साहित हैं, लेकिन अभी तक ऐसा करने के पर्याप्त अवसर नहीं हैं, तो यह फ़्लैग एक विकल्प होगा।

हम इस बात को लेकर काफी संशय में हैं कि व्यवहार में किसी को भी इस झंडे से कोई फायदा होगा। मानचित्र और मानचित्र जैसी चीज़ें अपनी परिभाषा साइटों पर पहले से ही | undefined में ऑप्ट इन कर सकती हैं

टाइपस्क्रिप्ट के लक्ष्यों में से एक नहीं है कि त्रुटियों को "संकलन" समय पर पकड़ने की अनुमति दी जाए, बजाय इसके कि उपयोगकर्ता को कुछ विशिष्ट करने के लिए याद रखने/जानने के लिए भरोसा किया जाए? ऐसा लगता है कि यह उस लक्ष्य के खिलाफ जा रहा है; क्रैश से बचने के लिए उपयोगकर्ता को कुछ करने की आवश्यकता होती है। कई अन्य विशेषताओं के लिए भी यही कहा जा सकता है; यदि डेवलपर हमेशा x करता है तो उनकी आवश्यकता नहीं होती है। टाइपस्क्रिप्ट का लक्ष्य (संभवतः) काम को आसान बनाना और इन चीजों को खत्म करना है।

मैं इस बग में आया क्योंकि मैं मौजूदा कोड पर strictNullChecks सक्षम कर रहा था और मेरे पास पहले से ही तुलना थी इसलिए मुझे त्रुटि मिली। अगर मैं बिल्कुल नया कोड लिख रहा होता तो शायद मुझे यहां इस मुद्दे का एहसास नहीं होता (टाइप सिस्टम मुझे बता रहा था कि मुझे हमेशा एक मूल्य मिल रहा है) और रनटाइम विफलता के साथ समाप्त हो गया। टीएस डेवलपर्स को याद रखने के लिए (या इससे भी बदतर, यहां तक ​​​​कि जानते हैं) कि वे अपने सभी मानचित्रों को | undefined साथ घोषित करने वाले हैं, ऐसा लगता है कि टाइपस्क्रिप्ट वह करने में विफल हो रहा है जो लोग वास्तव में इसके लिए चाहते हैं।

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

असल में लक्ष्य है:

1) उन निर्माणों की सांख्यिकीय रूप से पहचान करें जिनमें त्रुटि होने की संभावना है।

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

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

मैं इस टिप्पणी पर थोड़ा और तर्क में गया https://github.com/Microsoft/TypeScript/issues/11238#issuecomment -250562397

दुनिया में दो प्रकार की चाबियों के बारे में सोचें: जिन्हें आप जानते हैं उनके पास किसी वस्तु (सुरक्षित) में संबंधित संपत्ति होती है, जिन्हें आप नहीं जानते कि किसी वस्तु (खतरनाक) में संबंधित संपत्ति होती है।

सही कोड लिखने से आपको पहली तरह की कुंजी मिलती है, एक "सुरक्षित" कुंजी, जैसे

for (let i = 0; i < arr.length; i++) {
  // arr[i] is T, not T | undefined

या

for (const k of Object.keys(obj)) {
  // obj[k] is T, not T | undefined

आपको दूसरी तरह की कुंजी से मिलती है, "खतरनाक" प्रकार, उपयोगकर्ता इनपुट जैसी चीजों से, या डिस्क से यादृच्छिक JSON फाइलें, या कुछ चाबियों की सूची जो मौजूद हो सकती हैं लेकिन हो सकती हैं।

इसलिए यदि आपके पास खतरनाक प्रकार की कुंजी और इसके द्वारा अनुक्रमणिका है, तो यहां | undefined होना अच्छा होगा। लेकिन प्रस्ताव " खतरनाक चाबियों के साथ खतरनाक व्यवहार करें" नहीं है, यह " सभी चाबियों, यहां तक ​​​​कि सुरक्षित लोगों को भी खतरनाक मानें"। और एक बार जब आप सुरक्षित चाबियों को खतरनाक मानने लगते हैं, तो जीवन वास्तव में बेकार हो जाता है। आप जैसे कोड लिखते हैं

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

और टाइपप्रति आप कम से शिकायत कर रहा है कि arr[i] हो सकता है undefined भले ही हे मैं सिर्फ @ #% # इसके लिए परीक्षण किया आईएनजी देखो। अब आपको इस तरह कोड लिखने की आदत हो गई है, और यह मूर्खतापूर्ण लगता है:

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

या शायद आप इस तरह कोड लिखते हैं:

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k].name);
  }
}

और टाइपस्क्रिप्ट कहता है "अरे, वह सूचकांक अभिव्यक्ति | undefined हो सकती है, इसलिए आप इसे कर्तव्यपूर्वक ठीक कर सकते हैं क्योंकि आपने इस त्रुटि को पहले ही 800 बार देखा है:

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k]!.name); // Shut up TypeScript I know what I'm doing
  }
}

लेकिन आपने बग को ठीक नहीं किया । आप Object.keys(yourObj) , या शायद myObj[k] लिखना चाहते थे। यह सबसे खराब प्रकार की कंपाइलर त्रुटि है, क्योंकि यह वास्तव में किसी भी परिदृश्य में आपकी मदद नहीं कर रहा है - यह केवल हर तरह की अभिव्यक्ति के लिए एक ही अनुष्ठान लागू कर रहा है, इस पर ध्यान दिए बिना कि यह वास्तव में उसी रूप की किसी भी अन्य अभिव्यक्ति से अधिक खतरनाक था या नहीं।

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

उन निर्माणों की सांख्यिकीय रूप से पहचान करें जिनमें त्रुटियां होने की संभावना है।

शायद यह कहने के लिए इसे संशोधित करने की आवश्यकता है "स्थिर रूप से उन संरचनाओं की पहचान करें जो दूसरों की तुलना में त्रुटियों की पलक :. मुझे याद दिलाया जाता है कि जब हमें बग मिलते हैं जो अनिवार्य रूप से होते हैं "मैंने * का उपयोग किया था जब मेरा मतलब / का उपयोग करना था, क्या आप * एक चेतावनी बना सकते हैं?"

मैं समझता हूं, लेकिन सूचकांक सीमा से बाहर एक वास्तविक और सामान्य मुद्दा है; लोगों को इस तरह से सरणियों की गणना करने के लिए मजबूर करना कि वे ऐसा नहीं कर सकते, यह कोई बुरी बात नहीं होगी।

! साथ फिक्स मैं वास्तव में भी नापसंद करता हूं - क्या होगा यदि कोई साथ आता है और ऐसा परिवर्तन करता है कि धारणा अब अमान्य है? आप एक वर्ग में वापस आ गए हैं (कंपाइलर को पकड़ने वाली किसी चीज़ के लिए संभावित रनटाइम विफलता)। सरणियों की गणना करने के सुरक्षित तरीके होने चाहिए जो या तो प्रकारों के बारे में झूठ बोलने या ! का उपयोग करने पर भरोसा नहीं करते हैं (उदाहरण के लिए, क्या आप array.forEach(i => console.log(i.name) जैसा कुछ नहीं कर सकते हैं?)

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

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

वैसे भी, यह सिर्फ मेरे 2 सेंट हैं .. मैं इसे बाहर नहीं खींचना चाहता - मुझे यकीन है कि आप समझते हैं कि हम कहाँ से आ रहे हैं और आप मुझसे इस पर निर्णय लेने के लिए कहीं बेहतर हैं :-)

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

for (let i = 0; i < a.length; i++) {
  const value = a[i];
}

यदि आप मानते हैं कि अतिरिक्त सरणियाँ असामान्य हैं (वे हैं) तो value होना | undefined होना बहुत कम मदद करता है। यदि जंगली में एक सामान्य पैटर्न है, जहां यह जोखिम भरा है (और संभवतः एक त्रुटि है) तो मुझे लगता है कि टाइपस्क्रिप्ट इस पर विचार करने के लिए सुनेगा, लेकिन सामान्य उपयोग में आने वाले पैटर्न, फिर से सभी मूल्यों के खिलाफ फिर से इंडेक्स एक्सेस अपरिभाषित होना स्पष्ट रूप से कुछ ऐसा है जो उत्पादकता को प्रभावित करता है और जैसा कि बताया गया है, यदि आप ऐसी स्थिति में हैं जहां यह संभावित रूप से उपयोगी है, तो इसे चुना जा सकता है।

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

तो यह एक व्यापार बंद हो जाता है ... सीएफए सुधार के बिना, संभावित रूप से 10% खराब कोड को पकड़ने के लिए लाल झुंडों के साथ 90% कोड को जटिल करें। अन्यथा यह प्रमुख सीएफए सुधारों में निवेश कर रहा है, जो कि स्थिरता के अपने स्वयं के परिणामों और फिर से खिलाफ मुद्दों के साथ गढ़ा जा सकता है, यह पता लगाना कि असुरक्षित कोड क्या होगा।

हमें खुद से बचाने के लिए टाइपस्क्रिप्ट इतना ही कर सकता है।

यह सारा ध्यान सरणियों पर है और मैं मानता हूं कि इसमें कोई समस्या होने की संभावना कम है, लेकिन उठाए गए अधिकांश मूल मुद्दे (जैसे मेरा) उन मानचित्रों के बारे में थे जहां मुझे नहीं लगता कि सामान्य मामला हमेशा-मौजूदा कुंजी है?

यह सारा ध्यान सरणियों पर है और मैं मानता हूं कि इसमें कोई समस्या होने की संभावना कम है, लेकिन उठाए गए अधिकांश मूल मुद्दे (जैसे मेरा) उन मानचित्रों के बारे में थे जहां मुझे नहीं लगता कि सामान्य मामला हमेशा-मौजूदा कुंजी है?

यदि यह आपका प्रकार है, तो अनुक्रमणिका हस्ताक्षर में | undefined जोड़ें। --noImplicitAny तहत बिना किसी अनुक्रमणिका हस्ताक्षर वाले प्रकार में अनुक्रमित करना पहले से ही एक त्रुटि है।
ES6 Map को पहले से ही get(key: K): V | undefined; रूप में प्राप्त करने के साथ परिभाषित किया गया है।

मैं | undefined लौटने वाले इंडेक्स हस्ताक्षर बनाने के लिए Arrays और Maps की सभी परिभाषाओं को फिर से लिखता हूं, उसके बाद से कभी खेद नहीं हुआ, कुछ बग पाए गए, इससे कोई असुविधा नहीं होती क्योंकि मैं अप्रत्यक्ष रूप से एक हस्तनिर्मित lib के माध्यम से सरणी के साथ काम करता हूं जो चेक रखता है अपरिभाषित या इसके अंदर ! के लिए

बहुत अच्छा होगा यदि टाइपस्क्रिप्ट प्रवाह को नियंत्रित कर सकता है जैसे सी # करता है (कुछ प्रोसेसर समय बचाने के लिए इंडेक्स रेंज चेक को खत्म करने के लिए), उदाहरण के लिए:

declare var values: number[];
for (let index = 0, length = values.length; index< length; index ++) {
   const value = value[index]; // always defined, because index is within array range and only controlled by it
}

(उन लोगों के लिए जो विरल सरणियों का उपयोग करते हैं - अपने आप को गर्म जलती हुई आग से मारें)

जहां तक Object.keys सवाल है, तो नियंत्रण प्रवाह विश्लेषण को सुरक्षित रूप से सीमित करने के लिए allkeysof T कहने के लिए एक विशेष प्रकार की आवश्यकता होती है

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

आपकी ऑब्जेक्ट प्रकार परिभाषाओं में |undefined डालने के साथ (कम से कम) दो अन्य समस्याएं हैं:

• इसका मतलब है कि आप इन वस्तुओं में अपरिभाषित असाइन कर सकते
• अन्य संचालन, जैसे Object.values (या _.values ) के लिए आपको परिणामों में undefined को संभालने की आवश्यकता होगी

tslint निरंतर स्थिति की झूठी-सकारात्मक चेतावनी की रिपोर्ट करता है, क्योंकि टाइपस्क्रिप्ट गलत प्रकार की जानकारी देता है (= | undefined कमी)।
https://github.com/palantir/tslint/issues/2944

सरणी अनुक्रमण में | undefined की अनुपस्थिति के साथ नियमित रूप से छोड़ी गई त्रुटियों में से एक यह पैटर्न है जब find स्थान पर उपयोग किया जाता है:

const array = [ 1, 2, 3 ];
const firstFour = array.filter((x) => (x === 4))[0];
// if there is no `4` in the `array`,
// `firstFour` will be `undefined`, but TypeScript thinks `number` because of the indexer signature.

const array = [ 1, 2, 3 ];
const firstFour = array.find((x) => (x === 4));
// `firstFour` will be correctly typed as `number | undefined` because of the `find` signature.

मैं निश्चित रूप से इस ध्वज का उपयोग करूंगा। हां, पुराने for लूप के साथ काम करने में परेशानी होगी, लेकिन हमारे पास ! ऑपरेटर को कंपाइलर को बताने के लिए है जब हम जानते हैं कि यह परिभाषित है:

for (let i = 0; i < arr.length; i++) {
  foo(arr[i]!)
}

साथ ही, यह समस्या नए, बेहतर तरीके से for of लूप के साथ कोई समस्या नहीं है और यहां तक ​​​​कि एक TSLint नियम prefer-for-of जो आपको पुरानी शैली for लूप का उपयोग नहीं करने के लिए कहता है। अब और।

वर्तमान में मुझे लगता है कि टाइप सिस्टम डेवलपर के लिए असंगत है। array.pop() लिए if चेक या ! अभिकथन की आवश्यकता है, लेकिन [array.length - 1] माध्यम से एक्सेस करने की आवश्यकता नहीं है। ES6 map.get() को if चेक या ! अभिकथन की आवश्यकता होती है, लेकिन ऑब्जेक्ट हैश नहीं होता है। @sompylasar का उदाहरण भी अच्छा है।

एक और उदाहरण विनाशकारी है:

const specifier = 'Microsoft/TypeScript'
const [repo, revision] = specifier.split('@') // types of repo and revision are string
console.log('Repo: ' + repo)
console.log('Short rev: ' + revision.slice(0, 7)) // Error: Cannot call function 'slice' on undefined

अगर कंपाइलर ने मुझे ऐसा करने के लिए मजबूर किया होता तो मैं पसंद करता:

const specifier = 'Microsoft/TypeScript'
const [repo, revision] = specifier.split('@') // types of repo and revision are string | undefined
console.log('Repo: ', repo || 'no repo')
console.log('Short rev:', revision ? revision.slice(0, 7) : 'no revision')

ये वास्तविक बग हैं जिन्हें मैंने देखा है जिन्हें संकलक द्वारा रोका जा सकता था।

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

मुझे लगता है कि बहुत से लोग बिना किसी बग के ढीले होने के बजाय कुछ आवश्यक दावों के साथ संकलक को सख्त होना पसंद करेंगे।

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

@pelotom तब आपकी चिंता क्या है (क्योंकि ऐसा लगता है कि आप ज्यादातर खुद को परेशानी से बाहर निकाल चुके हैं)?

@ एलेक्सी-बायकोव ज्यादातर इंडेक्स सिग्नेचर पर ऑब्जेक्ट करते हैं, जो थर्ड-पार्टी लाइब्रेरी में बड़े पैमाने पर होते हैं। मुझे चेतावनी देने के लिए कि परिणाम संभवतः अपरिभाषित है, मैं { [k: string]: A } पर एक संपत्ति का उपयोग करना चाहता हूं। मैंने केवल सरणी अनुक्रमण का उल्लेख किया है क्योंकि इसे एक मामले के रूप में लाया गया था कि झंडा काम करने के लिए बहुत परेशान क्यों होगा।

आप जानते हैं कि आप उन्हें ठीक वैसे ही फिर से लिख सकते हैं जैसे आप चाहते हैं? (थोड़ा अतिरिक्त काम दिया गया)

हां, मैं उनके लिए हर किसी की टाइपिंग को फिर से लिख सकता हूं, या मैं एक कंपाइलर फ्लैग पर स्विच कर सकता हूं

कप्तान ओ खेलते रहें...: आप आज अपने lib.d.ts को फिर से लिख सकते हैं और अधिक ध्वनि कोडबेस के खुश मालिक बन सकते हैं या आप अगले एन वर्षों के लिए ध्वज की प्रतीक्षा कर सकते हैं

@ एलेक्सी-बायकोव lib.d.ts को फिर से लिखकर इसे कैसे किया जा सकता है?

declare type Keyed<T> = { [key: string]: T | undefined; }

फिर Array परिभाषा में lib.es2015.core.d.ts , प्रतिस्थापित करें

[n: number]: T;

साथ

[n: number]: T | undefined;

@ एलेक्सी-बायकोव शायद आप उस हिस्से से चूक गए जहां मैंने कहा था कि मुझे सरणियों की परवाह नहीं है। मुझे इस बात की परवाह है कि तीसरे पक्ष के पुस्तकालयों ने { [k: string]: T } प्रकार का कुछ घोषित किया है, और मैं संभावित रूप से अपरिभाषित कुछ वापस करने के लिए ऐसी वस्तु तक पहुंच बनाना चाहता हूं। केवल lib.d.ts संपादित करके इसे पूरा करने का कोई तरीका नहीं है; इसके लिए विचाराधीन पुस्तकालय के हस्ताक्षर बदलने की आवश्यकता है।

क्या आपके पास तृतीय पक्ष परिभाषा फ़ाइलों पर नियंत्रण है? यदि ऐसा है तो आप उन्हें ठीक कर सकते हैं

और अब हम वापस आ गए हैं

हां, मैं उनके लिए हर किसी की टाइपिंग को फिर से लिख सकता हूं, या मैं एक कंपाइलर फ्लैग पर स्विच कर सकता हूं

समय एक सपाट वृत्त है।

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

हां, मुझे हर समय दूसरों की टाइपिंग संपादित करनी पड़ती है और मैं इसे कम करना चाहूंगा।

और आप एन वर्षों में, हो सकता है, अभी के लिए आप पीड़ित हो सकते हैं या ऊपर उठ सकते हैं

आपके अविश्वसनीय रचनात्मक इनपुट के लिए धन्यवाद

इसके लिए रचनात्मक इनपुट इस प्रकार है, इस मुद्दे को बंद करने की आवश्यकता है, क्योंकि:
ए। या तो [x] undefined सकता है या नहीं, इस पर निर्णय डेवलपर्स पर छोड़ दिया जाता है

• उन्हें यह सब अपने दिमाग में रखने दें जैसा कि वे हमेशा पहले करते थे
• या सुझाव के अनुसार lib.d.ts और 3rd-party.d.ts को बदलकर

बी। या #a . में हाथों से आसानी से की जा सकने वाली किसी चीज़ को कम करने के लिए विशेष सिंटैक्स / प्रकार / प्रवाह विश्लेषण / N वर्ष लगते हैं

मुद्दा (बी) के लिए एक प्रस्ताव है, सिवाय इसके कि कोई नया वाक्यविन्यास प्रस्तावित नहीं किया जा रहा है, यह सिर्फ एक कंपाइलर ध्वज है।

यह नीचे आता है कि { [x: string]: {} } प्रकार लगभग हमेशा झूठ होता है; Proxy के उपयोग को छोड़कर, ऐसी कोई वस्तु नहीं है जिसमें अनंत संख्या में गुण हों, हर संभव स्ट्रिंग बहुत कम। प्रस्ताव एक संकलक ध्वज है जो इसे पहचानता है। यह हो सकता है कि जो हासिल हुआ है उसके लिए इसे लागू करना बहुत कठिन है; मैं उस कॉल को कार्यान्वयनकर्ताओं पर छोड़ दूँगा।

बात यह है कि न तो

• T | undefined
• न ही T

सामान्य मामले के लिए सही है

सामान्य स्थिति के लिए इसे सही बनाने के लिए आपको मूल्यों के प्रीरेंस के बारे में जानकारी को उनके कंटेनरों के प्रकारों में एन्कोड करने की आवश्यकता होती है जो एक निर्भर प्रकार प्रणाली की मांग करते हैं ... जो स्वयं ही एक बुरी चीज नहीं है :) लेकिन यह उतना ही जटिल हो सकता है जितना कि आज तक की गई सभी मौजूदा टाइपस्क्रिप्ट प्रकार प्रणाली के लिए ... आपको कुछ संपादन बचाने के लिए?

T | undefined सामान्य मामले के लिए सही है, जिन कारणों से मैंने अभी दिया है। आश्रित प्रकारों के बारे में अपने निरर्थक जुमले को नज़रअंदाज़ कर देंगे, आपका दिन शुभ हो।

आप जितना चाहें मुझे अनदेखा कर सकते हैं लेकिन T | undefined लिए एक ओवरशूट है

declare var items: number[];
for (var index = 0; index < items.length; index ++) {
   void items[index];
}

मैं नहीं बल्कि होगा T | undefined वहाँ डिफ़ॉल्ट रूप से और संकलक कि बता index के एक संख्यात्मक इंडेक्स रेंज है items इस तरह बाहर नहीं मिलता है, तो जब करने के लिए लागू सीमा items ; साधारण मामलों में जैसे कि अक्सर उपयोग किए जाने वाले for / while लूप आकृतियों का एक सेट, संकलक स्वचालित रूप से इसका अनुमान लगा सकता है; जटिल मामलों में, क्षमा करें, undefined s हो सकता है। और हाँ, मूल्य-आधारित प्रकार यहाँ उपयुक्त होंगे; शाब्दिक स्ट्रिंग प्रकार इतने उपयोगी हैं, शाब्दिक बूलियन और संख्या और श्रेणी/सेट-ऑफ-रेंज प्रकार क्यों नहीं हैं? जहां तक ​​टाइपस्क्रिप्ट जाता है, यह जावास्क्रिप्ट के साथ व्यक्त की जा सकने वाली हर चीज को कवर करने की कोशिश करता है (इसके विपरीत, उदाहरण के लिए, एल्म जो इसे सीमित करता है)।

यह सचमुच एक विशिष्ट परियोजना के लिए अधिकतम काम का दिन है, क्या यह किया गया है

@ एलेक्सी-बायकोव, जिज्ञासु उस बदलाव के बाद आपका अनुभव क्या था? आपको कितनी बार ! ? और आप कितनी बार कंपाइलर को वास्तविक बग्स को फ़्लैग करते हुए पाते हैं?

@mhegazy ईमानदारी से मैंने T से T | undefined तक जाने में बहुत अंतर नहीं देखा, न ही मैंने कोई बग पकड़ा, मुझे लगता है कि मेरी समस्या यह है कि मैं उपयोगिता कार्यों के माध्यम से सरणी के साथ काम करता हूं जो ! रखता है

https://github.com/aleksey-bykov/basic/blob/master/array.ts

मैं किस lib फ़ाइल में वस्तुओं के लिए अनुक्रमणिका प्रकार की परिभाषा ढूँढ सकता हूँ? मैंने Array को [n: number]: T से [n: number]: T | undefined ढूंढा और अपडेट किया है। अब मैं वस्तुओं के लिए भी यही काम करना चाहूंगा।

अनुक्रमणिका हस्ताक्षर वाली वस्तुओं के लिए कोई मानक इंटरफ़ेस नहीं है (जैसे Array सरणियों के लिए), आपको अपने कोड में प्रत्येक मामले के लिए सटीक परिभाषाएँ देखने और उन्हें ठीक करने की आवश्यकता है

आपको अपने कोड में प्रत्येक मामले के लिए सटीक परिभाषाओं को देखने और उन्हें ठीक करने की आवश्यकता है

प्रत्यक्ष कुंजी लुकअप के बारे में कैसे? उदाहरण के लिए

const xs = { foo: 'bar' }
xs['foo']

वहाँ लागू करने के लिए कोई तरीका है T | undefined के बजाय T यहाँ? वर्तमान में मैं हर जगह अपने कोडबेस में इन हेल्पर्स का उपयोग करता हूं, जैसे कि सरणियों और वस्तुओं पर इंडेक्स लुकअप के लिए सुरक्षित विकल्प:

// TS doesn't return the correct type for array and object index signatures. It returns `T` instead
// of `T | undefined`. These helpers give us the correct type.
// https://github.com/Microsoft/TypeScript/issues/13778
export const getIndex = function<X> (index: number, xs: X[]): X | undefined {
  return xs[index];
};
export const getKeyInMap = function<X> (key: string, xs: { [key: string]: X }): X | undefined {
  return xs[key];
};

@mhegazy जैसा कि मैंने इसे लिखा है, मैं https://unsplash.com पर उत्पादन में एक बग को ठीक कर रहा हूं जिसे सख्त इंडेक्स हस्ताक्षर प्रकारों के साथ पकड़ा जा सकता था।

मैं देखता हूं, मैप किए गए प्रकार के ऑपरेटर पर विचार करें:

const xs = { foo: 'bar' };
type EachUndefined<T> = { [P in keyof T]: T[P] | undefined; }
const xu : EachUndefined<typeof xs> = xs;
xu.foo; // <-- string | undefined

यदि --strictArrayIndex जैसा कोई फ़्लैग विकल्प नहीं है क्योंकि फ़्लैग को lib.d.ts फ़ाइलों को बदलने के लिए डिज़ाइन नहीं किया गया है। हो सकता है कि आप लोग lib.d.ts फाइलों के सख्त संस्करण जारी कर सकें जैसे " lib": ['strict-es6'] ?

इसमें कई सुधार हो सकते हैं, न कि केवल सख्त सरणी अनुक्रमणिका। उदाहरण के लिए, Object.keys :

interface ObjectConstructor {
    // ...
    keys(o: {}): string[];
}

हो सकता है:

interface ObjectConstructor {
    // ...
    keys<T>(o: T): (keyof T)[];
}

आज के एसबीएस से अपडेट: हम 30 मिनट तक एक-दूसरे पर चिल्लाते रहे और कुछ नहीं हुआ। ‍♂️

@RyanCavanaugh एक SBS क्या है, जिज्ञासा से बाहर?

@radix "सुझाव बैकलॉग

यह पेचीदा है, क्योंकि समाधान स्पष्ट है:
दोनों T और T | undefined गलत हैं, एक ही सही तरीका है कि इंडेक्स वेरिएबल को इसके कंटेनर की क्षमता से अवगत कराया जाए, या तो सेट से उठाकर या किसी ज्ञात संख्यात्मक रेंज में संलग्न करके

@RyanCavanaugh मैं इस बारे में सोच रहा था, ऐसा लगता है कि निम्नलिखित चाल में सभी मामलों में से 87% शामिल होंगे:

• values[index] T यदि सूचकांक for (HERE; ...) में घोषित किया गया हो
• values[somethingElse] T | undefined के बाहर घोषित सभी चरों के लिए for

@aleksey-bykov हमने कुछ और भी बेहतर चर्चा की - कि " arr[index] लिए एक वास्तविक प्रकार का गार्ड तंत्र हो सकता है index < arr.length द्वारा परीक्षण किया गया था। लेकिन यह उस मामले में मदद नहीं करेगा जहां आप pop 'd बीच में एक लूप, या अपने सरणी को उस फ़ंक्शन में पास कर दिया जिसने तत्वों को हटा दिया। ऐसा वास्तव में ऐसा नहीं लगता है कि लोग ऐसे तंत्र की तलाश में हैं जो ओओबी त्रुटियों को 82.9% समय से रोकता है - आखिरकार , यह पहले से ही मामला है कि सरणी-अनुक्रमण कोड का लगभग वह अंश वैसे भी सही है। गलत मामलों में बग न पकड़ते हुए सही कोड में समारोह जोड़ना एक बुरा परिणाम है।

_{इसका मतलब यह नहीं है कि एलेक्सी कभी भी एक सरणी को बदल देगा}

मैंने हाल ही में एल्म से टाइपस्क्रिप्ट में एक ऐप पोर्ट किया है और इंडेक्सिंग ऑपरेशंस को गलत तरीके से टाइप किया जा रहा है, शायद मेरे द्वारा चलाए गए बग के सबसे बड़े स्रोतों में से एक है, टीएस सक्षम की सभी सख्त सेटिंग्स के साथ ( this अनबाउंड होने की तरह सामान भी) )

• आप कंटेनर में उत्परिवर्तन ट्रैक नहीं कर सकते
• आप सूचकांक जोड़तोड़ को ट्रैक नहीं कर सकते

इसके साथ कहा गया है कि आप बहुत कम गारंटी दे सकते हैं, यदि ऐसा है तो आप कोशिश क्यों करेंगे यदि एक विशिष्ट उपयोग का मामला < array.length भीतर सभी तत्वों के माध्यम से गूंगा पुनरावृत्ति है

जैसे मैंने आमतौर पर कहा

• यदि कोई त्रुटि है, तो यह संभवतः for स्टेटमेंट के क्लॉज में कहीं से उत्पन्न होता है: आरंभीकरण, वेतन वृद्धि, स्टॉप कंडीशन और इस प्रकार कुछ ऐसा नहीं है जिसे आप सत्यापित कर सकते हैं, क्योंकि इसके लिए ट्यूरिंग पूर्ण टाइपचेकिंग की आवश्यकता होती है
• for क्लॉज के बाहर आमतौर पर त्रुटि के लिए कोई जगह नहीं होती है

इसलिए जब तक सूचकांक किसी तरह घोषित किया जाता है (हम इसके बारे में विश्वास के साथ कुछ नहीं कह सकते हैं) यह विश्वास करना उचित है कि सूचकांक लूप बॉडी के साथ सही है

लेकिन इससे उस मामले में मदद नहीं मिलेगी जहां आपने बीच में एक लूप पॉप किया था, या अपने सरणी को उस फ़ंक्शन में पास कर दिया था जिसने तत्वों को हटा दिया था

यह इसके खिलाफ एक बहुत ही कमजोर तर्क की तरह लगता है। वे मामले पहले ही टूट चुके हैं - अन्य मामलों को ठीक न करने के बहाने के रूप में उनका उपयोग करने का कोई मतलब नहीं है। यहां कोई भी उन मामलों में से किसी एक को सही ढंग से संभालने के लिए नहीं कह रहा है और न ही इसे 100% सही होने के लिए कह रहा है। हम वास्तव में एक सामान्य मामले में सटीक प्रकार चाहते हैं। टाइपस्क्रिप्ट में ऐसे कई मामले हैं जिन्हें पूरी तरह से नियंत्रित नहीं किया जाता है; यदि आप कुछ अजीब कर रहे हैं, तो प्रकार गलत हो सकते हैं। इस मामले में हम कुछ भी अजीब नहीं कर रहे हैं और प्रकार गलत हैं।

सही कोड में समारोह जोड़ना

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

बग नहीं पकड़ते समय

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

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

हम कुछ भी अजीब नहीं कर रहे हैं और प्रकार गलत हैं।

यह पैराग्राफ, मेरे लिए, इस सुविधा के न होने के एक अच्छे कारण की तरह पढ़ता है। किसी सरणी को सीमा से बाहर एक्सेस करना एक अजीब बात है; प्रकार केवल "गलत" हैं यदि आप एक असामान्य काम कर रहे हैं (OOBing)। एक सरणी से कोड पढ़ने का विशाल बहुमत ऐसा इन-बाउंड करता है; इस तर्क द्वारा उन मामलों में undefined को शामिल करना "गलत" होगा।

... वर्किंग कोड जो संकलित करने में विफल रहता है

मुझे किसी के बारे में पता नहीं है - क्या आप उन्हें विशेष रूप से इंगित कर सकते हैं?

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

इस और एक TSLint नियम के बीच उपयोगी अंतर क्या है जो कहता है कि "सभी सरणी एक्सेस एक्सप्रेशन में पिछला ! होना चाहिए"?

@RyanCavanaugh मेरी धारणा यह है कि TSLint नियम संकीर्ण प्रकारों या नियंत्रण-प्रवाह प्रकार विश्लेषण का उपयोग करने में सक्षम नहीं होगा (उदाहरण के लिए if में पहुंच को लपेटना, अपवाद फेंकना, return आईएनजी या continue अगर यह सेट नहीं है, आदि)। यह केवल ऐरे एक्सेस एक्सप्रेशन के बारे में नहीं है, यह विनाश के बारे में भी है। https://github.com/Microsoft/TypeScript/issues/13778#issuecomment -336265143 में उदाहरण के लिए कार्यान्वयन कैसा दिखेगा? ! को लागू करने के लिए, इसे अनिवार्य रूप से undefined रूप में इन चरों के प्रकारों को ट्रैक करने के लिए एक तालिका बनानी होगी। जो मेरे लिए कुछ ऐसा लगता है जो टाइप चेकर को करना चाहिए, लिंटर नहीं।

@RyanCavanaugh

यह पैराग्राफ, मेरे लिए, इस सुविधा के न होने के एक अच्छे कारण की तरह पढ़ता है। किसी सरणी को सीमा से बाहर एक्सेस करना एक अजीब बात है; प्रकार केवल "गलत" हैं यदि आप एक असामान्य काम कर रहे हैं (OOBing)।

... वर्किंग कोड जो संकलित करने में विफल रहता है

मुझे किसी के बारे में पता नहीं है - क्या आप उन्हें विशेष रूप से इंगित कर सकते हैं?

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

इसे हमेशा किसी चीज़ की तुलना undefined

जो शर्म की बात है

const canWeDoIt = null === undefined; // yes we can!

इसे हमेशा किसी चीज़ की तुलना undefined

बहुत समय हो गया है, मुझे डर है कि मुझे ठीक से याद नहीं है कि त्रुटि क्या थी। मुझे निश्चित रूप से उस कोड के लिए एक त्रुटि थी जो ठीक काम कर रहा था (बिना strictNullChecks ) और यह मुझे उस परीक्षण की ओर ले गया जिसके परिणामस्वरूप उपरोक्त मामला सामने आया।

अगर मुझे कुछ समय मिलता है, तो मैं देखूंगा कि क्या मैं यह पता लगा सकता हूं कि यह फिर से क्या था। यह निश्चित रूप से इस टाइपिंग से संबंधित था।

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

export type Chooser = (context?: Context) => number | string;
export interface Choices {
    [choice: number]: Struct;
    [choice: string]: Struct;
}

export const Branch = (chooser: Chooser, choices: Choices, context?: Context): Struct => {
    return choices[chooser(context)];  // Could be undefined
}

वस्तुओं के संबंध में और केवल | undefined शामिल करने के लिए हस्ताक्षर बदलना, @types/node ऐसा करता है process.env :

    export interface ProcessEnv {
        [key: string]: string | undefined;
    }

लेकिन यह इस प्रकार को बिल्कुल भी कम करने की अनुमति नहीं देता है:

process.env.SOME_CONFIG && JSON.parse(process.env.SOME_CONFIG)

देता है

[ts]
Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
  Type 'undefined' is not assignable to type 'string'.

@felixfbecker

मेरा मानना ​​है कि यह इस बग से संबंधित है: https://github.com/Microsoft/TypeScript/issues/17960

आप एक चर के लिए env var निर्दिष्ट करके और फिर उसकी रखवाली करके इसे हल कर सकते हैं:

const foo = process.env.SOME_CONFIG
foo && JSON.parse(foo);

कुछ नोड टाइपिंग में | undefined जोड़ना कोड को पूरा करने के लिए अक्सर उपयोग किए जाने वाले गुणों के साथ इन इंटरफेस की सुविधा के लिए वृद्धि की अनुमति देने के लिए किया गया था। ईए

interface ProcessEnv {
  foo?: string;
  bar?: string;
}

इंडेक्स सिग्नेचर में | undefined बिना TSC शिकायत करता है Property 'foo' of type 'string | undefined' is not assignable to string index type 'string'. ।

मुझे पता है कि इसकी एक लागत है यदि आपको अतिरिक्त | undefined वाले प्रकारों के साथ काम करना है और जिनके पास यह नहीं है।

वास्तव में अच्छा होगा यदि हम इससे छुटकारा पा सकें।

मैं इस मुद्दे पर अपने विचार एकत्र करने की कोशिश कर रहा हूं।

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

• शब्दकोश उर्फ ​​नक्शे, जहां चाबियाँ अज्ञात हैं
• रिकॉर्ड, जहां चाबियाँ ज्ञात हैं

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

शब्दकोशों (उर्फ मानचित्र) और सरणियों के रूप में उपयोग की जाने वाली वस्तुओं के लिए, सूचकांक हस्ताक्षर का उपयोग किया जाता है, और हम मूल्य प्रकार में | undefined शामिल करना चुन सकते हैं। उदाहरण के लिए, { [key: index]: string | undefined } । सभी कुंजियाँ लुकअप मान्य हैं (क्योंकि कुंजियाँ संकलन समय पर ज्ञात नहीं होती हैं), और सभी कुंजियाँ एक ही प्रकार की होती हैं (इस उदाहरण में, T | undefined )।

इंडेक्स सिग्नेचर के रूप में केवल डिक्शनरी ऑब्जेक्ट पैटर्न और एरेज़ के लिए उपयोग किया जाना चाहिए, यह वांछित है कि टाइपस्क्रिप्ट को इंडेक्स सिग्नेचर वैल्यू टाइप में | undefined लागू करना चाहिए: यदि कुंजियाँ ज्ञात नहीं हैं, और कुंजी लुकअप संभवतः undefined लौटाते हैं

बग के अच्छे उदाहरण हैं जो इसके बिना अदृश्य दिखाई दे सकते हैं, जैसे Array.prototype.find undefined लौटाना, या प्रमुख लुकअप जैसे array[0] रिटर्निंग undefined । (कुंजी लुकअप के लिए विनाश सिर्फ चीनी वाक्यविन्यास है।) रिटर्न प्रकार को सही करने के लिए getKey जैसे कार्यों को लिखना संभव है, लेकिन हमें कोडबेस में इन कार्यों के उपयोग को लागू करने के लिए अनुशासन पर भरोसा करना होगा।

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

क्या यह बकाया मुद्दा है, या क्या मैं गलत समझ रहा हूँ?

मैंने किन मामलों और समस्याओं का उल्लेख नहीं किया है?

आपके ऑब्जेक्ट प्रकार परिभाषाओं में | अपरिभाषित डालने के साथ (कम से कम) दो अन्य समस्याएं हैं:

• इसका मतलब है कि आप इन वस्तुओं में अपरिभाषित असाइन कर सकते हैं, जो निश्चित रूप से इरादा नहीं है
• अन्य संचालन, जैसे Object.values ​​​​(या _.values) आपको परिणामों में अपरिभाषित को संभालने की आवश्यकता होगी

मुझे लगता है कि यह एक बहुत ही महत्वपूर्ण बिंदु है।

फिलहाल, मैं निम्नलिखित दृष्टिकोण के साथ प्रयोग कर रहा हूं:

const safelyAccessProperty = <T, K extends keyof T>(object: T, key: K): T[K] | undefined => object[key]; परिभाषित करें

की तरह फिर पहुँच गुण safelyAccessProperty(myObject, myKey) , के बजाय myObject[myKey] ।

@plul अच्छी पकड़। चर्चा वर्तमान में रीड ऑपरेशंस पर केंद्रित है, लेकिन इंडेक्सर प्रकार की परिभाषा वास्तव में दो गुना है, और | undefined जोड़ने से undefined मान लिखने की अनुमति मिल जाएगी।

आप जिस safelyAccessProperty फ़ंक्शन के साथ प्रयोग कर रहे हैं (@OliverJAsh द्वारा getKey रूप में ऊपर उल्लिखित ) सभी सरणियों और वस्तुओं पर अनुक्रमण संचालन को प्रतिबंधित करने के लिए अनुशासन और/या एक लिंटर नियम की आवश्यकता है।

इसे स्केलेबल बनाया जा सकता है यदि फ़ंक्शन सभी सरणी और ऑब्जेक्ट इंस्टेंसेस (हर प्रकार जो इंडेक्सर ऑपरेशंस प्रदान करता है) पर प्रदान किया जाता है, जैसे सी ++ std::vector में .at() जो ओओबी एक्सेस के लिए रनटाइम में अपवाद फेंकता है , और एक अनियंत्रित [] ऑपरेटर जो सबसे अच्छी स्थिति में OOB एक्सेस पर SEGFAULT के साथ क्रैश हो जाता है, सबसे खराब स्थिति में मेमोरी को दूषित कर देता है।

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

इंडेक्सर की दो-गुना प्रकृति को get और set कार्यों के साथ एक संपत्ति के रूप में मॉडलिंग किया जा सकता है, लेकिन यह सभी मौजूदा इंडेक्सर प्रकार परिभाषाओं के लिए एक ब्रेकिंग परिवर्तन होगा।

एक विचार जो ऐसा लगता है कि यह आशाजनक हो सकता है: क्या होगा यदि आप इंडेक्स हस्ताक्षर को परिभाषित करते समय ?: उपयोग कर सकते हैं यह इंगित करने के लिए कि आप सामान्य उपयोग के तहत कभी-कभी मूल्यों के गायब होने की उम्मीद करते हैं? यह ऊपर वर्णित | undefined तरह कार्य करेगा, लेकिन अजीब डाउनसाइड्स के बिना। इसे स्पष्ट undefined मानों को अस्वीकार करने की आवश्यकता होगी, जो मुझे लगता है कि सामान्य ?: से एक अंतर है।

यह इस तरह दिखेगा:

type NewWay = {[key: string]?: string};
const n: NewWay = {};

// Has type string | undefined
n['foo']

// Has type Array<string>
Object.values(n)

// Doesn't work
n['foo'] = undefined;

// Works
delete n['foo'];

| undefined के पिछले दृष्टिकोण की तुलना में:

type OldWay = {[key: string]: string | undefined};
const o: OldWay = {};

// Has type string | undefined
o['foo']

// Has type Array<string | undefined>
Object.values(o)

// Works
o['foo'] = undefined;

// Works
delete o['foo'];

मैं ऊपर डीटी पीआर में | undefined जोड़ने को अस्वीकार करने से यहां आया था, क्योंकि यह उस एपीआई के सभी मौजूदा उपयोगकर्ताओं को तोड़ देगा - क्या इसे बेहतर तरीके से देखा जा सकता है क्योंकि उपयोगकर्ता को यह चुनने की इजाजत है कि वे कितना उग्र होना चाहते हैं, बल्कि पुस्तकालय की तुलना में?

मैं नोट करूंगा कि वैकल्पिक गुण | undefined भी जोड़ते हैं, और इसने मुझे कुछ बार काटा है - अनिवार्य रूप से TS एक लापता संपत्ति और अपरिभाषित पर सेट की गई संपत्ति के बीच अंतर नहीं करता है। मैं चाहता हूं कि { foo?: T, bar?: T } को { [name: 'foo' | 'bar']: T } के समान माना जाए, जो भी हो (ऊपर process.env टिप्पणियां भी देखें)

क्या टीएस संख्या और स्ट्रिंग इंडेक्सर्स पर समरूपता को तोड़ने के खिलाफ है?

foo[bar] && foo[bar].baz() एक बहुत ही सामान्य JS पैटर्न है, जब यह TS द्वारा समर्थित नहीं होता है तो यह अनाड़ी लगता है (आपको यह याद दिलाने के अर्थ में कि यदि आप | undefined नहीं जोड़ते हैं, और जब यह स्पष्ट रूप से आवश्यक नहीं है यदि आप करते हैं)।

गार्ड एक्सप्रेशन गारंटी को तोड़ने वाले पुनरावृत्ति के दौरान सरणियों को बदलने के संबंध में, यह अन्य गार्डों के साथ भी संभव है:

class Foo {
    foo: string | number = 123

    bar() {
        this.foo = 'bar'
    }

    broken() {
        if (typeof this.foo === 'number') {
            this.bar();
            this.foo.toLowerCase(); // right, but type error
            this.foo.toExponential(); // wrong, but typechecks
        }
    }
}

लेकिन मुझे लगता है कि वास्तविक कोड में यह बहुत कम संभावना है कि पुराने लूप पुनरावृत्त को बदलते हैं।

साफ है कि इस फीचर की डिमांड है। मुझे वाकई उम्मीद है कि टीएस टीम कुछ समाधान ढूंढ लेगी। इंडेक्सर में केवल | undefined जोड़कर नहीं क्योंकि इसके अपने मुद्दे हैं (पहले से ही उल्लेख किया गया है) लेकिन अधिक "चालाक" तरीके से (रिटर्न T|undefined पढ़ना, लेखन के लिए T आवश्यकता होती है, अच्छा कंपाइलर for लूप, आदि के लिए जाँच करना। अच्छे प्रस्ताव का भी पहले ही उल्लेख किया गया था।)

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

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

let arr!: string[];
if (arr.length == 3) {
  //arr is of type [string, string, string]
}

if (arr.length > 3) {
  //arr is of type [string, string, string, string, ...string[]]
}

if (arr.length) {
  //arr is of type [string, ...string[]]
}

if (arr.length < 3) {
  //arr is of type [string?, string?, string?]
  if (arr.length > 0) {
    //arr is of type [string, string?, string?]
  }
}

यह तब उपयोगी होगा जब आप किसी सरणी को स्थिर या नष्ट करके अनुक्रमित करते हैं।

let someNumber = 55;
if (arr.length) {
  let el1 = arr[0]; //string
  let el2 = arr[1]; //string | undefined
  let el3 = arr[someNumber]; //string | undefined
}

if(arr.length >= 3){
    let [el1, el2, el3, el4] = arr;
    //el1, el2, el3 are string
    // el4 is string | undefined    
}

if (arr.length == 2){
    let [el1, el2, el3] = arr; //compiler error: "Tuple type '[string, string]' with length '2' cannot be assigned to tuple with length '3'.",
}

अन्य प्रश्न यह है कि हम बड़ी संख्या के साथ क्या करेंगे जैसे:

if(arr.length >= 99999){
    // arr is [string, string, ... , string, ...string[]]
}

हम IDE या कंपाइलर संदेशों में इस विशाल टपल का प्रकार नहीं दिखा सकते हैं।

मुझे लगता है कि हमारे पास "सभी वस्तुओं के लिए एक ही प्रकार के साथ निश्चित लंबाई के टुपल" का प्रतिनिधित्व करने के लिए कुछ वाक्यविन्यास हो सकता है। तो उदाहरण के लिए 1000 तारों का टपल string[10000] और उपरोक्त उदाहरण से संकुचित सरणी का प्रकार [...string[99999], ...string[]] ।

दूसरी चिंता यह है कि यदि कंपाइलर इन्फ्रास्ट्रक्चर अब इतने बड़े टुपल्स का समर्थन कर सकता है, और यदि नहीं, तो यह करना कितना कठिन होगा।

वस्तुओं

मैं हमेशा [key: string (or number, symbol)]: V | undefined का एक इंडेक्स प्रकार चाहता हूं, केवल कभी-कभी मैं undefined मामले को भूल जाता हूं। जब भी किसी देव को स्पष्ट रूप से संकलक को बताना होता है "मेरा विश्वास करो, यह वास्तविक के लिए उस चीज़ का प्रकार है" आप जानते हैं कि यह असुरक्षित है।
Map.get ठीक से (कड़ाई से) टाइप करना बहुत कम समझ में आता है लेकिन किसी भी तरह सादे वस्तुओं को एक मुफ्त पास मिलता है।
फिर भी, उपयोगकर्ता भूमि में इसे आसानी से ठीक किया जा सकता है, इसलिए यह बहुत बुरा नहीं है। मेरे पास कोई समाधान नहीं है, किसी भी दर पर।

सरणियों

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

मुझे लगता है कि अधिक से अधिक लोग इन दो सर्वोत्तम प्रथाओं का पालन करते हैं:

• Arrays को पुनरावृत्त या रूपांतरित करने के लिए कार्यात्मक मूल विधियों या पुस्तकालयों का उपयोग करें। यहां कोई ब्रैकेट एक्सेस नहीं है।
• Arrays को जगह में न बदलें

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

यह बिना दिमाग के लगता है और मुझे नहीं लगता कि पूरे lib.d.ts को स्थानीय रूप से कॉपी-पेस्ट करना एक स्वीकार्य समाधान है।

जब हम किसी ऐरे/ऑब्जेक्ट में स्पष्ट रूप से इंडेक्स करते हैं, उदाहरण के लिए किसी ऐरे ( array[0] ) का पहला आइटम प्राप्त करने के लिए, हम चाहते हैं कि परिणाम में undefined ।

यह इंडेक्स सिग्नेचर में undefined जोड़कर संभव है।

हालांकि, अगर मैं सही ढंग से समझता हूं, तो इंडेक्स हस्ताक्षर में undefined शामिल करने के साथ समस्या यह है कि, सरणी या ऑब्जेक्ट पर मैपिंग करते समय, मानों में undefined शामिल होगा, भले ही वे ज्ञात न हों undefined (अन्यथा हम उन पर मैपिंग नहीं करेंगे)।

इंडेक्स प्रकार/हस्ताक्षर का उपयोग इंडेक्स लुकअप (जैसे array[0] ) और मैपिंग (जैसे for लूप और Array.prototype.map ) दोनों के लिए किया जाता है, लेकिन हमें इनमें से प्रत्येक मामले के लिए अलग-अलग प्रकार की आवश्यकता होती है।

यह Map साथ कोई समस्या नहीं है क्योंकि Map.get एक फ़ंक्शन है, और इसलिए इसका रिटर्न प्रकार आंतरिक मान प्रकार से अलग हो सकता है, एक सरणी/ऑब्जेक्ट में अनुक्रमण के विपरीत जो फ़ंक्शन नहीं है, और इसलिए सीधे सूचकांक हस्ताक्षर का उपयोग करता है।

तो, सवाल बन जाता है: हम दोनों मामलों को कैसे संतुष्ट कर सकते हैं?

// Manually adding `undefined` to the index signature
declare const array: (number | undefined)[];

const first = array[0]; // number | undefined, as desired :-)
type IndexValue = typeof array[0]; // number | undefined, as desired! :-)

array.map(x => {
  x // number | undefined, not desired! :-(
})

प्रस्ताव

एक कंपाइलर विकल्प जो इंडेक्स लुकअप (जैसे array[0] ) को Set.get और Map.get टाइप करता है, इंडेक्स वैल्यू टाइप में undefined को शामिल करके (नहीं) सूचकांक हस्ताक्षर ही)। वास्तविक अनुक्रमणिका हस्ताक्षर में undefined शामिल नहीं होगा, ताकि मानचित्रण कार्य प्रभावित न हों।

उदाहरण:

declare const array: number[];

// The compiler option would include `undefined` in the index value type
const first = array[0]; // number | undefined, as desired :-)
type IndexValue = typeof array[0]; // number | undefined, as desired :-)

array.map(x => {
  x // number, as desired :-)
})

हालांकि यह for लूप का उपयोग करके सरणी/वस्तुओं पर लूपिंग के मामले को हल नहीं करेगा, क्योंकि वह तकनीक इंडेक्स लुकअप का उपयोग करती है।

for (let i = 0; i < array.length; i++) {
  const x = array[i];
  x; // number | undefined, not desired! :-(
}

मेरे लिए और मुझे कई अन्य लोगों पर संदेह है, यह स्वीकार्य है क्योंकि for लूप का उपयोग नहीं किया जाता है, इसके बजाय कार्यात्मक शैली का उपयोग करना पसंद करते हैं, जैसे Array.prototype.map । यदि हमें उनका उपयोग करना होता है, तो हम गैर-शून्य अभिकथन ऑपरेटरों के साथ यहां सुझाए गए कंपाइलर विकल्प का उपयोग करके खुश होंगे।

for (let i = 0; i < array.length; i++) {
  const x = array[i]!;
  x; // number, as desired :-)
}

हम ऑप्ट-इन या ऑप्ट-आउट करने का एक तरीका भी प्रदान कर सकते हैं, उदाहरण के लिए इंडेक्स सिग्नेचर को सजाने के लिए कुछ सिंटैक्स के साथ (कृपया उस अस्पष्ट सिंटैक्स को क्षमा करें जिसे मैं उदाहरण के लिए लेकर आया था)। यह सिंटैक्स केवल यह संकेत देने का एक तरीका होगा कि हम इंडेक्स लुकअप के लिए कौन सा व्यवहार चाहते हैं।

ऑप्ट-आउट (कंपाइलर विकल्प डिफ़ॉल्ट रूप से सक्षम करता है, जहां आवश्यक हो वहां ऑप्ट-आउट करें):

declare const array: { [index: number]!!: string };

declare const dictionary: { [index: string]!!: string }

ऑप्ट-इन (कोई कंपाइलर विकल्प नहीं, जहां आवश्यक हो वहां केवल ऑप्ट-इन करें):

declare const array: { [index: string]!!: string };

declare const dictionary: { [index: string]??: string }

मैंने इस मुद्दे या पेशेवरों और विपक्षों, विभिन्न प्रस्तावों आदि पर पढ़ा नहीं है (बस इसे Google में बार-बार आश्चर्यचकित होने के बाद पाया गया कि सरणी/ऑब्जेक्ट एक्सेस को सख्त शून्य जांच के साथ लगातार नियंत्रित नहीं किया जाता है), लेकिन मेरे पास एक है संबंधित सुझाव: सरणी प्रकार के अनुमान को यथासंभव सख्त बनाने का विकल्प जब तक कि विशेष रूप से ओवरराइड न हो।

उदाहरण के लिए:

const balls = [1, 2 ,3];

डिफ़ॉल्ट रूप से, balls को [number, number, number] माना जाएगा। इसे लिखकर ओवरराइड किया जा सकता है:

const balls: number[] = [1, 2 ,3];

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

const balls: [number, number, number] = [1, 2 ,3];
const n = balls[100];

मैं टुपल प्रकार की परिभाषा में .push जैसे सरणी उत्परिवर्तन विधियों की भी अपेक्षा करता हूं, क्योंकि ऐसी विधियां रन-टाइम प्रकार को संकलन-समय प्रकार के साथ असंगत होने के लिए बदलती हैं।

@buu700 टाइपस्क्रिप्ट 3.0 में आपका स्वागत है: https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-typescript-3-0/#richer -tuple-types

अच्छा! वैसे यह दिलचस्प समय है। मैं रिलीज की घोषणा खोल चुका था, लेकिन अभी तक इसे पढ़ा नहीं था; केवल उस स्थिति में चलने के बाद यहां आया जहां मुझे टाइपस्क्रिप्ट (2.9) को वह करने के लिए कुछ अजीब कास्टिंग ( (<(T|undefined)[]> arr).slice(-1)[0] ) करने की आवश्यकता थी जो मैं करना चाहता था।

बस चीजों को इस सुझाव पर वापस लाना चाहता था: https://github.com/Microsoft/TypeScript/issues/13778#issuecomment -383072468

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

@mhegazy @RyanCavanaugh मेरे प्रस्ताव पर कोई विचार? https://github.com/Microsoft/TypeScript/issues/13778#issuecomment -406316164

मेरे लिए, एक आसान उपाय है। एक ध्वज सक्षम करें जो इसकी जांच करता है। फिर, इसके बजाय:

const array = [1, 2, 3];
for (var i =0; i< array.length; i++) {
    array[i]+=1; // array[i] is possibly undefined
}

तुम करो:

const array = [1, 2, 3];
array.forEach((value, i) => array[i] = value + 1);

फिर, रैंडम इंडेक्स एक्सेस करते समय, आपको यह जांचना आवश्यक है कि क्या परिणाम अपरिभाषित है, लेकिन एक एन्यूमरेटेड संग्रह को पुनरावृत्त करते समय नहीं।

मुझे अभी भी लगता है कि यह वारंट एक खुला मुद्दा है।

एक प्रोग्रामर के रूप में जो टाइपस्क्रिप्ट के लिए नया है, मैंने पाया कि सख्त मोड में वस्तुओं को अनुक्रमित करने के आसपास की स्थिति अनपेक्षित है। मैं एक लुकअप के परिणाम T | undefined होने की उम्मीद करता, इसी तरह Map.get । वैसे भी, मैं अभी हाल ही में इसमें भाग गया, और पुस्तकालय में एक मुद्दा खोला:

स्क्रीपर्स/टाइप्ड-स्क्रीप्स#107

मैं शायद इसे अभी बंद करने जा रहा हूं, क्योंकि ऐसा लगता है कि कोई अच्छा समाधान नहीं है। मुझे लगता है कि मैं थोड़ा उपयोगिता फ़ंक्शन का उपयोग करके T | undefined में "ऑप्टिंग-इन" करने का प्रयास करने जा रहा हूं:

export function lookup<T>(map: {[index: string]: T}, index: string): T|undefined {
  return map[index];
}

ऑब्जेक्ट इंडेक्स ऑपरेशन रिटर्न प्रकार के रूप में स्पष्ट रूप से T | undefined सेट करने के लिए यहां कुछ सुझाव दिए गए थे, हालांकि यह काम नहीं कर रहा है:

const obj: {[key: string]: number | undefined} = {
  "a": 1,
  "b": 2,
};

const test = obj["c"]; // const test: number

यह वीएससीओडी संस्करण 1.31.1 है

@yawaramin सुनिश्चित करें कि आपके tsconfig.json में strictNullChecks सक्षम है (जो strict ध्वज द्वारा भी सक्षम है)

यदि आपके उपयोग के मामले में अज्ञात लंबाई के सरणी पर मनमाने ढंग से अनुक्रमण की आवश्यकता है, तो मुझे लगता है कि यह अपरिभाषित स्पष्ट रूप से जोड़ने लायक है (यदि केवल "दस्तावेज़" के लिए असुरक्षितता)।

const words = ... // some string[] that could be empty
const x = words[0] as string | undefined
console.log(x.length) // TS error

टुपल्स ज्ञात लंबाई के छोटे सरणियों के लिए काम करते हैं। हो सकता है कि हमारे पास string[5] लिए शॉर्टहैंड के रूप में [string, string, string, string, string] जैसा कुछ हो सकता है?

एक विकल्प के रूप में इसके पक्ष में बहुत कुछ। यह टाइप सिस्टम में एक ध्यान देने योग्य छेद है, खासकर जब strictNullChecks ध्वज सक्षम है। JS में हर समय प्लेन ऑब्जेक्ट्स को मैप्स के रूप में उपयोग किया जाता है, इसलिए टाइपस्क्रिप्ट को उस उपयोग के मामले का समर्थन करना चाहिए।

फ़ंक्शन पैरामीटर को नष्ट करने वाले सरणी के साथ इसमें भाग लें:

function foo([first]: string[]) { /* ... */ }

यहां मैं a प्रकार string | undefined होने की अपेक्षा करता हूं लेकिन यह केवल string , जब तक कि मैं ऐसा नहीं करता

function foo([first]: (string | undefined)[]) { /* ... */ }

मुझे नहीं लगता कि हमारे कोड बेस में हमारे पास एक भी for लूप है, इसलिए मैं इस व्यवहार को टॉगल करने के लिए खुशी से अपने tsconfig के कंपाइलर विकल्पों (नाम strictIndexSignatures ) में एक ध्वज जोड़ूंगा हमारी परियोजना के लिए।

इस तरह से मैं इस मुद्दे पर काम कर रहा हूं: https://github.com/danielnixon/total-functions/

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

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

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

मैं का उपयोग कर के साथ एक समस्या में भाग | undefined नक्शे के साथ आज का उपयोग करते समय Object.entries() ।

मेरे पास एक इंडेक्स प्रकार है जिसे {[key: string]: string[]} द्वारा काफी अच्छी तरह से वर्णित किया गया है, स्पष्ट चेतावनी के साथ कि इंडेक्स में हर स्ट्रिंग कुंजी संभव नहीं है। हालांकि, मैंने एक बग लिखा था जिसे इंडेक्स से देखे गए मूल्य का उपभोग करने की कोशिश करते समय टीएस पकड़ में नहीं आया; अपरिभाषित मामले को संभाला नहीं।

इसलिए मैंने इसे अनुशंसित के अनुसार {[key: string]: string[] | undefined} में बदल दिया, लेकिन अब यह मेरे Object.entries() उपयोग के साथ समस्याओं का कारण बनता है। टाइपस्क्रिप्ट अब मानता है (यथोचित, प्रकार विनिर्देश के आधार पर) कि सूचकांक में कुंजियाँ हो सकती हैं जिनका मान अपरिभाषित निर्दिष्ट है, और इसलिए Object.entries() पर कॉल करने के परिणाम में अपरिभाषित मान हो सकते हैं।

हालाँकि, मैं जानता हूँ कि यह असंभव है; केवल एक बार जब मुझे undefined परिणाम मिलना चाहिए, वह एक ऐसी कुंजी की तलाश कर रहा है जो मौजूद नहीं है, और जो Object.entries() का उपयोग करते समय सूचीबद्ध नहीं होगी। तो टाइपस्क्रिप्ट को खुश करने के लिए मुझे या तो कोड लिखना होगा जिसका कोई वास्तविक कारण नहीं है, या चेतावनियों को ओवरराइड करें, जिसे मैं नहीं करना पसंद करूंगा।

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

(उदाहरण अभी भी मेरे लिए कुछ हद तक असंबद्ध हैं, लेकिन इस धागे ने पहले ही सभी तर्क दिए हैं, एक और टिप्पणी कुछ भी बदलने वाली नहीं है)

अगर कोई अपने lib.d.ts को संशोधित करना चाहता है और अपने कोड में सभी डाउनस्ट्रीम ब्रेक को ठीक करना चाहता है और दिखाता है कि समग्र अंतर कैसा दिखता है, यह दिखाने के लिए कि इसमें कुछ मूल्य प्रस्ताव है, हम उस डेटा के लिए खुले हैं।

@RyanCavanaugh यहाँ मेरी कोड आधार से मामलों में जहां कुछ क्रम दुर्घटनाओं slumbering रहे हैं। ध्यान दें कि मेरे पास पहले से ही ऐसे मामले थे जहां मैं इस वजह से उत्पादन में दुर्घटनाग्रस्त हो गया था और एक हॉटफिक्स जारी करने की आवश्यकता थी।

src={savedAdsItem.advertImageList.advertImage[0].mainImageUrl || undefined}

return advert.advertImageList.advertImage.length ? advert.advertImageList.advertImage[0].mainImageUrl : ''

birthYear: profileData.birthYear !== null ? profileData.birthYear : allowedYears[0].value,

upsellingsList.upsellingProducts[0].upsellingProducts[0].selected = true

const latitude = parseFloat(coordinates.split(',')[0])

const advert = Object.values(actionToConfirm.selectedItems)[0]
await dispatch(deactivateMyAd(advert))

इस मामले में यह कष्टप्रद होगा क्योंकि ArticleIDs extends articleNames[] में परिणामी मूल्यों में undefined है, जबकि इसे पूरी तरह से परिभाषित सबसेट की अनुमति देनी चाहिए। आसानी से उपयोग करके सुधारी जा सकने वाली ReadonlyArray<articleNames> के बजाय articleNames[] ।

export enum articleNames {
    WEB_AGB = 'web_agb',
    TERMS_OF_USE = 'web_terms-of-use',
}
export const getMultipleArticles = async <ArticleIDs extends articleNames[], ArticleMap = { [key in ArticleIDs[number]]: CmsArticle }>(ids: ArticleIDs): Promise<ArticleMap> => {...}

कुल मिलाकर मैं संभावित रनटाइम क्रैश को रोकने के लिए वास्तव में इस अतिरिक्त प्रकार की सुरक्षा चाहता हूं।

मैं इस टिप्पणी पर थोड़ा और तर्क में गया # 11238 (टिप्पणी)

दुनिया में दो प्रकार की चाबियों के बारे में सोचें: जिन्हें आप जानते हैं _do_ में किसी वस्तु (सुरक्षित) में एक समान संपत्ति होती है, जिन्हें आप नहीं जानते कि किसी वस्तु (खतरनाक) में संबंधित संपत्ति होती है।

सही कोड लिखने से आपको पहली तरह की कुंजी मिलती है, एक "सुरक्षित" कुंजी, जैसे

for (let i = 0; i < arr.length; i++) {
  // arr[i] is T, not T | undefined

या

for (const k of Object.keys(obj)) {
  // obj[k] is T, not T | undefined

आपको दूसरी तरह की कुंजी से मिलती है, "खतरनाक" प्रकार, उपयोगकर्ता इनपुट जैसी चीजों से, या डिस्क से यादृच्छिक JSON फाइलें, या कुछ चाबियों की सूची जो मौजूद हो सकती हैं लेकिन हो सकती हैं।

इसलिए यदि आपके पास खतरनाक प्रकार की कुंजी और इसके द्वारा अनुक्रमणिका है, तो यहां | undefined होना अच्छा होगा। लेकिन प्रस्ताव "खतरनाक_ कुंजियों के साथ खतरनाक व्यवहार करें" नहीं है, यह "सभी _ कुंजियों, यहां तक ​​कि सुरक्षित कुंजियों को भी खतरनाक मानें"। और एक बार जब आप सुरक्षित चाबियों को खतरनाक मानने लगते हैं, तो जीवन वास्तव में बेकार हो जाता है। आप जैसे कोड लिखते हैं

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

और टाइपप्रति आप कम से शिकायत कर रहा है कि arr[i] हो सकता है undefined भले ही _hey मैं सिर्फ @ #% # it_ के लिए परीक्षण किया आईएनजी देखो। अब आपको इस तरह कोड लिखने की आदत हो गई है, और यह मूर्खतापूर्ण लगता है:

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

या शायद आप इस तरह कोड लिखते हैं:

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k].name);
  }
}

और टाइपस्क्रिप्ट कहता है "अरे, वह सूचकांक अभिव्यक्ति | undefined हो सकती है, इसलिए आप इसे कर्तव्यपूर्वक ठीक कर सकते हैं क्योंकि आपने इस त्रुटि को पहले ही 800 बार देखा है:

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k]!.name); // Shut up TypeScript I know what I'm doing
  }
}

लेकिन आपने बग को ठीक नहीं किया । आप Object.keys(yourObj) , या शायद myObj[k] लिखना चाहते थे। यह सबसे खराब प्रकार की कंपाइलर त्रुटि है, क्योंकि यह वास्तव में किसी भी परिदृश्य में आपकी मदद नहीं कर रहा है - यह केवल हर तरह की अभिव्यक्ति के लिए एक ही अनुष्ठान लागू कर रहा है, इस पर ध्यान दिए बिना कि यह वास्तव में उसी रूप की किसी भी अन्य अभिव्यक्ति से अधिक खतरनाक था या नहीं।

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

मैं डिलीट फाइल डायलॉग सादृश्य से सहमत हूं, हालांकि मुझे लगता है कि इस सादृश्य को उपयोगकर्ता को कुछ ऐसा जांचने के लिए मजबूर करने के लिए भी बढ़ाया जा सकता है जो संभवतः अपरिभाषित या शून्य है, इसलिए यह स्पष्टीकरण वास्तव में समझ में नहीं आता है, क्योंकि यदि यह स्पष्टीकरण सत्य है, strictNullChecks विकल्प समान व्यवहार को प्रेरित करने वाला है, उदाहरण के लिए document.getElementById का उपयोग करके DOM से कुछ तत्व प्राप्त करना।

लेकिन ऐसा नहीं है, बहुत सारे टाइपस्क्रिप्ट उपयोगकर्ता चाहते हैं कि कंपाइलर ऐसे कोड के बारे में झंडा उठाए ताकि उन किनारे के मामलों को Cannot access property X of undefined त्रुटि को फेंकने के बजाय उचित रूप से संभाला जा सके जो ट्रेस करना बहुत कठिन है।

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

ऐरे या ऑब्जेक्ट को गलत तरीके से एक्सेस करने की बात करने की संभावना नहीं है, क्या आपके पास इस दावे का बैकअप लेने के लिए कोई डेटा है? या यह सिर्फ मनमानी आंत की भावना पर आधारित है?

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

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

इस मामले को सुरक्षित रखने के लिए टाइपस्क्रिप्ट के नियंत्रण प्रवाह आधारित प्रकार विश्लेषण में सुधार किया जा सकता है

यह वास्तव में नहीं कर सकता।

declare function someFunc(arr: number[], i: number): void;
let arr = [1, 2, 3, 4];
for (let i = 0; i < arr.length; i++) {
  someFunc(arr, arr[i]);
}

क्या यह फ़ंक्शन लूप के माध्यम से दूसरे पास पर undefined से someFunc पास करता है, या नहीं? ऐसी बहुत सी चीज़ें हैं जिन्हें मैं someFunc में लिख सकता हूँ जिसके परिणामस्वरूप बाद में undefined ।

इस बारे में क्या?

declare function someFunc(arr: number[], i: number): void;
let arr = [1, 2, 3, 4];
let alias = arr;
for (let i = 0; i < arr.length; i++) {
  someFunc(alias, arr[i]);
}

@fabb मुझे एक और उदाहरण दें:

```
$ नोड

कास्ट गिरफ्तारी = []
अपरिभाषित
गिरफ्तारी [7] = 7
7
आगमन
[ <7 खाली आइटम>, ७ ]
के लिए (चलो i = 0; i < arr.length; i++) {
... कंसोल.लॉग (गिरफ्तारी [i])
...}
अपरिभाषित
अपरिभाषित
अपरिभाषित
अपरिभाषित
अपरिभाषित
अपरिभाषित
अपरिभाषित
7
अपरिभाषित```

@RyanCavanaugh के बाद से आप यहां हैं, item :: T लिए arr :: T[] में for (const item of arr) ... उल्लेख करने के बारे में, और अन्यथा arr[i] :: T | undefined का उपयोग करते समय कुछ --strict-index ? उस मामले के बारे में जो मुझे परवाह है, obj[key] :: V | undefined लेकिन Object.values(obj) :: V[] obj :: { [key: string]: V } ?

@yawaramin यदि आप विरल सरणियों का उपयोग कर रहे हैं, तो टाइपस्क्रिप्ट पहले से ही सही काम नहीं करता है। एक --strict-index ध्वज इसे ठीक कर देगा। यह संकलित करता है:

const arr = []
arr[7] = 7

for (let i = 0; i < arr.length; i++) {
    console.log(Math.sqrt(arr[i]));
}

@RyanCavanaugh एक बहुत ही सामान्य उदाहरण है कि मैं आपको दिखा सकता हूं कि उपयोगकर्ता गलत तरीके से सरणी तक पहुंचने के लिए प्रवण हैं।

const getBlock = (unitNumber: string): string => unitNumber.split('-')[0]

ऊपर दिए गए कोड को strictNullChecks तहत कंपाइलर चेकिंग पास नहीं करना चाहिए, क्योंकि getBlock कुछ उपयोग अपरिभाषित हो जाएंगे, उदाहरण के लिए getBlock('hello') ऐसे मामलों में मैं गंभीरता से चाहता हूं कंपाइलर उठाना ध्वज ताकि मैं अपने आवेदन को विस्फोट किए बिना अपरिभाषित मामलों को इनायत से संभाल सकूं।

और यह बहुत सारे सामान्य मुहावरों पर भी लागू होता है जैसे किसी सरणी के अंतिम तत्व तक पहुंचना arr.slice(-1)[0] , पहले तत्व तक पहुंच arr[0] आदि।

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

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

@RyanCavanaugh हां, जावास्क्रिप्ट खुद को अपरिवर्तनीयता के लिए उधार नहीं देता है। इस मामले में या तो एक ! आवश्यक होना चाहिए, या एक ReadonlyArray सरणी: someFunc(arr: ReadonlyArray<number>, i: number) ।

@yawaramin विरल सरणियों के लिए, तत्व प्रकार को संभवतः undefined शामिल करने की आवश्यकता होती है जब तक कि टाइपस्क्रिप्ट यह नहीं निकाल सकता कि इसका उपयोग टुपल की तरह किया जाता है। कोड में @danielnixon (https://github.com/microsoft/TypeScript/issues/13778#issuecomment-536248028) से लिंक किया गया है, undefined है। चूंकि कंपाइलर गारंटी देता है कि केवल सेट इंडेक्स का उपयोग किया जाता है।

यह एक सचेत निर्णय है। इस कोड के लिए त्रुटि होना बहुत कष्टप्रद होगा:

var a = [];
for (var i =0; i< a.length; i++) {
    a[i]+=1; // a[i] is possibly undefined
}

अरे, मैं उस वाक्य रचना को पहचानता हूं; मैं इस तरह से लूप लिखता हूँ शायद साल में एक बार!

मैंने पाया कि ज्यादातर मामलों में जहां मैं वास्तव में एक सरणी में अनुक्रमणिका करता हूं, मैं वास्तव में बाद में undefined जांच करना चाहता हूं।

इस विशेष मामले को काम करने के लिए कठिन बनाने की आशंका अधिक प्रतीत होती है। यदि आप केवल तत्वों पर पुनरावृति करना चाहते हैं तो आप for .. of उपयोग कर सकते हैं। यदि आपको किसी कारण से तत्व अनुक्रमणिका की आवश्यकता है, तो forEach या entries से अधिक पुनरावृति करें। आम तौर पर यह बेहद दुर्लभ है कि आपको वास्तव में लूप के लिए इंडेक्स-आधारित की आवश्यकता होती है।

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

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

पर शुक्र, 25 अक्टूबर, 2019 को 11:59 पूर्वाह्न brunnerh [email protected] लिखा है:

यह एक सचेत निर्णय है। इस कोड के लिए यह बहुत कष्टप्रद होगा
त्रुटि हो:

var a = []; for (var i =0; i< a.length; i++) {
ए[i]+=1; // ए [i] संभवतः अपरिभाषित है
}

अरे, मैं उस वाक्य रचना को पहचानता हूं; मैं इस तरह से लूप लिखता हूँ शायद साल में एक बार!

मैंने पाया कि ज्यादातर मामलों में जहां मैं वास्तव में एक सरणी में अनुक्रमणिका करता हूं, i
वास्तव में बाद में अपरिभाषित की जांच करना चाहते हैं।

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

यदि कोई बेहतर कारण हैं कि कोई यथास्थिति क्यों चाहता है, तो मैं
उन्हें देखना पसंद करते हैं, लेकिन परवाह किए बिना: यह व्यवस्था में एक विसंगति है
और ऐसा लगता है कि इसे ठीक करने के लिए ध्वज होने से कई लोगों द्वारा इसकी सराहना की जाएगी।

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

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

@brunnerh मैं for लूप का उपयोग करने की भी आवश्यकता नहीं है जब तक कि यह प्रदर्शन ट्यूनिंग के लिए न हो, जो कि मेरी कंपनी के कोडबेस में 0% समय होता है, क्योंकि अधिकांश समय नक्शा बदल रहा है /फ़िल्टर/लूप के लिए कम करना शायद ही कभी प्रदर्शन में सुधार करता है, असली अपराधी हमेशा अक्षम तर्क, नेटवर्क समस्या और डेटाबेस कनेक्शन के बारे में होता है।

मुझे आश्चर्य है कि किसी ने अभी तक as const बारे में बात नहीं की।

const test = [1, 2, 3] as const;

(test[100]).toFixed(5);
// Tuple type 'readonly [1, 2, 3]' of length '3' has no element at index '100'.

अधिक आम तौर पर, और इस मुद्दे के प्रारंभिक संदेश से बिल्कुल संबंधित नहीं है, मैं पिछले महीनों से निम्नलिखित रक्षात्मक प्रोग्रामिंग पैटर्न का उपयोग कर रहा हूं, और यह अच्छी तरह से काम करता है (मेरे लिए)

const xs: Array<number | undefined> = [1,2,3];

// for objects but kind of related as well
Record<string, User | undefined>

interface Something {
  [key: string]: User | undefined
}

हालांकि इसके लिए कोई संक्षिप्त संकेत नहीं है (जैसे ? ), मुझे लगता है कि यह ठीक है। कंपाइलर को स्वयं बताएं कि आप सुनिश्चित नहीं हो सकते हैं कि मान परिभाषित किया गया है, ठीक है।

@martpie as const यदि आप इसका उपयोग कर सकते हैं, तो यह बहुत अच्छा है।

कम से कम दो कारण हैं कि मैं Array<T | undefined> उपयोग क्यों नहीं करूंगा:

1. हर बार जब आप किसी सरणी का उपयोग करते हैं तो यह एक और बात याद रखनी होती है। इसके अलावा, आप अब केवल निहित टाइपिंग का उपयोग नहीं कर सकते हैं, जो कि अच्छा है।
2. यह forEach , map और filter के हस्ताक्षरों को बदल देता है, जो undefined को तत्व तर्क के रूप में पास नहीं करते हैं (जब तक कि सूचकांक स्पष्ट रूप से उस तरह से सेट नहीं किया जाता है)। इस पर निर्भर करता है कि आप उन कार्यों का कितना उपयोग करते हैं जिनसे निपटने में परेशानी हो सकती है।

मैं यह भी कहना चाहता हूं कि यह अब एस्लिंट/टाइपस्क्रिप्ट में बहुत सारी झूठी सकारात्मकता का कारण बनता है:

const a: string[] = [];
const foo = a[1000];
if (foo) { // eslint says this is an unnecessary conditional
  console.log(foo.length);
}

एस्लिंट (सही ढंग से) इस प्रकार से अनुमान लगाता है कि यह एक अनावश्यक जांच है, क्योंकि फू कभी भी शून्य नहीं हो सकता है। तो अब मुझे न केवल सचेत रूप से याद रखना है कि मैं एक सरणी से वापस आने वाली चीजों पर एक शून्य जांच करना चाहता हूं, मुझे _ भी_ एक एस्लिंट अक्षम लाइन जोड़नी है! और इस तरह के लूप के बाहर की चीजों को एक्सेस करना वस्तुतः एकमात्र तरीका है जिससे हम कभी भी ऐरे एक्सेस करते हैं, क्योंकि (जैसे कि इन दिनों शायद अधिकांश टीएस देव), हम सरणियों पर लूपिंग करते समय forEach/map/filter/etc फ़ंक्शन का उपयोग करते हैं।

मुझे सच में लगता है कि हमारे पास बस एक नया कंपाइलर ध्वज होना चाहिए जो डिफ़ॉल्ट रूप से सत्य पर सेट हो यदि strict सत्य है, और यदि लोग इसे पसंद नहीं करते हैं, तो वे ऑप्ट आउट कर सकते हैं। हमने हाल के संस्करणों में वैसे भी नए ब्रेकिंग सख्त कंपाइलर चेक जोड़े हैं।

यह हाल की स्मृति में देखे गए _only_ रनटाइम प्रोड बग्स का स्रोत है जो टाइप सिस्टम की विफलता थी।

अब उपलब्ध वैकल्पिक चेनिंग ऑपरेटर के एर्गोनॉमिक्स को ध्यान में रखते हुए, शायद यह निर्णय _not_ को ध्वज के माध्यम से उपलब्ध कराने के निर्णय पर फिर से विचार करने का समय है?

अगर मुझे सर्वर से Thing की एक सरणी मिलती है, और मुझे सरणी में अंतिम Thing प्रदर्शित करने की आवश्यकता है, तो मैं आमतौर पर जो कुछ चलाता हूं वह यह है कि सरणी वास्तव में खाली है, और एक संपत्ति तक पहुंच उस Thing पर ऐप क्रैश हो जाता है।

उदाहरण:

// `things` is `Thing[]`, but is empty, i.e., `[]`
const { things } = data; 

// We are accessing `things[-1]`, which is obviously `undefined`, 
// but TypeScript thinks `latestThing` is a `Thing`
const latestThing = things[things.length - 1];

// TypeError: Cannot read property 'foo' of undefined
return latestThing.foo; 

हो सकता है कि यह हमारे एपीआई के डिजाइन के साथ एक मुद्दा है, लेकिन ऐसा लगता है कि टीएस को यह समझना चाहिए कि जब आप सरणी में कुछ एक्सेस करते हैं, तो यह वास्तव में वहां नहीं हो सकता है।

संपादित करें: बस स्पष्ट करना चाहता हूं कि मेरा मतलब "हमारा एपीआई" है जैसा कि "मैं जिस टीम पर काम कर रहा हूं, उसके द्वारा बनाई गई एपीआई"

हां, हर कोई काफी हद तक सहमत है कि यह एक बहुत ही खराब डिजाइन निर्णय है, एक दूरस्थ समय के समकालीन जब टीएस पूरी तरह से असुरक्षित था।

वर्कअराउंड के रूप में, मैं एक छोटे से गंदे हैक का उपयोग करता हूं। मैं सिर्फ package.json साधारण पोस्टइंस्टॉल स्क्रिप्ट में जोड़ता हूं:

{
...
  "scripts": {
    "postinstall": "sed -i 's/\\[n: number\\]: T;/[n: number]: T | undefined;/g' node_modules/typescript/lib/lib.es5.d.ts",
    ...
  },
...
}

बेशक, यह विंडोज़ पर काम नहीं करेगा, लेकिन यह कुछ भी नहीं से बेहतर है।

इसके आस-पास चलने वाले अन्य सभी मुद्दे यहां पुनर्निर्देशित होने लगते हैं, इसलिए मुझे लगता है कि यह पूछने के लिए सबसे अच्छी जगह है: टेबल से वैकल्पिक इंडेक्स हस्ताक्षर के लिए शॉर्टहैंड सिंटैक्स है? जैसा कि @martpie बताता है, आपको interface Foo { [k: string]: Bar | undefined; } लिखना होगा जो कि interface Foo { [k: string]?: Bar; } से कम एर्गोनोमिक है।

क्या हमें ?: ऑपरेटर सपोर्ट मिल सकता है? यदि नहीं, तो क्यों नहीं? यही है, एकल संपत्ति परिभाषा के लिए सुविधा जोड़ने के लिए एर्गोनोमिक लाभ पर्याप्त था - क्या यह अनुक्रमणिका हस्ताक्षर के लिए "पर्याप्त सहायक" नहीं है?

type Foo = { [_ in string]?: Bar } भी काम करता है। उतना सुंदर नहीं, लेकिन काफी संक्षिप्त। यदि आप चाहें तो अपना खुद का Dict प्रकार भी बना सकते हैं। हालांकि, ?: एक्सटेंशन के खिलाफ बहस नहीं करेंगे

यह उन "जावास्क्रिप्ट: द बैड पार्ट्स" वार्ताओं में से एक जैसा लगने लगा है:

ts type Foo1 = { [_ in string]?: Bar } // Yup type Foo2 = { [_: string]?: Bar } // Nope interface Foo3 { k?: Bar } // Yup interface Foo4 { [_: string]?: Bar } // Nope

हस्ताक्षर प्रकार के लिए T | undefined का उपयोग करना वास्तव में उपयोगी नहीं है। हमें इसे बनाने का एक तरीका चाहिए ताकि इंडेक्स ऑपरेटर [n] में T|undefined प्रकार हो, लेकिन उदाहरण के लिए किसी सरणी पर map का उपयोग करने से हमें T|undefined नहीं मिलना चाहिए मूल्य, क्योंकि उस स्थिति में हमें पता होना चाहिए कि वे मौजूद हैं।

@radix ऐरे पर वास्तविक कार्यों के लिए, मुझे नहीं लगता कि यह एक समस्या होगी क्योंकि उन सभी की अपनी प्रकार की परिभाषाएं हैं जो सही प्रकार का उत्पादन करती हैं: जैसे map : https://github.com/microsoft /टाइपस्क्रिप्ट/ब्लॉब/मास्टर/lib/lib.es5.d.ts#L1331

केवल सामान्य कोड उपयोग जो | undefined निर्माण में अनुभव का वास्तविक प्रतिगमन होता है वह for ... of लूप में होता है। दुर्भाग्य से (इस मुद्दे के दृष्टिकोण से), वे सामान्य निर्माण हैं।

@riggs मुझे लगता है कि आप interface Array<T> { } बनाने के बारे में बात कर रहे हैं [index: number]: T | undefined , लेकिन @radix संभवतः वर्तमान अनुशंसा के बारे में बात कर रहा है, जिसका उपयोग करना है Array<T | undefined> में आपका अपना कोड।

उत्तरार्द्ध कई कारणों से खराब है, जिनमें से कम से कम यह नहीं है कि आप अन्य पैकेजों के प्रकारों को नियंत्रित नहीं करते हैं, लेकिन पूर्व में कुछ समस्याएं भी हैं, अर्थात् आप सरणी को undefined असाइन कर सकते हैं, और यह कि ज्ञात सुरक्षित मामलों में भी undefined देता है। ‍♂️

आह, हाँ, मेरी गलतफहमी। वास्तव में, मैं केवल [index: number]: T | undefined परिभाषा का उपयोग करने का जिक्र कर रहा था। मैं पूरी तरह से सहमत हूं कि एक प्रकार को Array<T | undefined> रूप में परिभाषित करना एक भयानक काम है जो हल होने की तुलना में अधिक समस्याओं का कारण बनता है।

क्या lib.es5.d.ts को ओवरराइड करने का कोई शानदार तरीका है या पोस्टइंस्टॉल स्क्रिप्ट जाने का सबसे अच्छा तरीका है?

@ निकु-chiciuc https://www.npmjs.com/package/patch-package पूरी तरह से साथ एक विधर्मी के पिटारे में फिट बैठता है https://www.npmjs.com/package/yalc ✌️

क्या lib.es5.d.ts को ओवरराइड करने का कोई शानदार तरीका है या पोस्टइंस्टॉल स्क्रिप्ट जाने का सबसे अच्छा तरीका है?

हमारे प्रोजेक्ट में हमारे पास एक global.d.ts फ़ाइल है जिसका उपयोग हम 1 के लिए करते हैं) बिल्ट-इन एपीआई के लिए टाइप परिभाषाएँ जोड़ना जो अभी तक टाइपस्क्रिप्ट की डिफ़ॉल्ट प्रकार परिभाषाओं में नहीं हैं (उदाहरण के लिए वेबआरटीसी-संबंधित एपीआई जो लगातार बदल रहे हैं और सभी ब्राउज़रों में असंगत हैं) ) और 2) टाइपप्रति के डिफ़ॉल्ट प्रकार परिभाषाएं में से कुछ अधिभावी (जैसे के प्रकार अधिभावी Object.entries इतना है कि यह युक्त सरणियों रिटर्न unknown के बजाय any )।

मुझे यकीन नहीं है कि इस मुद्दे को हल करने के लिए टाइपस्क्रिप्ट के सरणी प्रकारों को ओवरराइड करने के लिए इस दृष्टिकोण का उपयोग किया जा सकता है, लेकिन यह एक कोशिश के लायक हो सकता है।

उपरोक्त काम करता है जब घोषणा विलय आपको इच्छित परिणाम देता है, लेकिन सरल बनाने के लिए वे इंटरफेस को छेड़छाड़ करते हैं, लेकिन यहां कम प्रतिबंधात्मक विकल्प वह है जो आप चाहते हैं।

इसके बजाय आप उन सभी lib.*.d.ts फ़ाइलों को कॉपी-पेस्ट करने का प्रयास कर सकते हैं जिनका उपयोग आप अपने प्रोजेक्ट में कर रहे हैं, tsconfig.json के files या include , फिर उन्हें संपादित करें आप क्या चाहते हैं। चूंकि उनमें /// <reference no-default-lib="true"/> , /// <reference lib="..."/> को हटाना होगा या नहीं। यह निश्चित रूप से सभी स्पष्ट रखरखाव कारणों के लिए बुरा है।

@butchler हम भी इस दृष्टिकोण का उपयोग कर रहे हैं लेकिन ऐसा लगता है कि इंडेक्सिंग ऑपरेटर को ओवरराइड करना संभव नहीं था, हालांकि हमने कुछ अन्य ऐरे फ़ंक्शंस ( filter टाइप गार्ड के साथ) को सफलतापूर्वक ओवरराइड कर दिया है।

इंडेक्सिंग ऑपरेटर को ओवरराइड करने के साथ मेरे पास एक अजीब मामला है:

function test() {
  const arr: string[] = [];

  const [first] = arr;
  const zero = arr[0];

  const str1: string = first;
  const str2: string = zero;
}

दूसरा असाइनमेंट गलत करता है (जैसा कि इसे करना चाहिए), फिर भी पहला वाला नहीं करता है।
यहां तक ​​​​कि अजीब बात यह है कि first पर मँडराते हुए इसे नष्ट किया जा रहा है, यह दर्शाता है कि इसमें string | undefined का एक प्रकार है, फिर भी इसे सौंपा जा रहा है, यह दर्शाता है कि इसमें string का एक प्रकार है

क्या सरणी विनाशकारी के लिए एक अलग प्रकार की परिभाषा है?

इसका समाधान खोज रहे हैं क्योंकि लापता इंडेक्स से संबंधित त्रुटियां मेरे कोड में बग का लगातार स्रोत रही हैं।

{ [index: string]: string | undefined } जैसे प्रकार को निर्दिष्ट करना कोई समाधान नहीं है, क्योंकि यह Object.values(x).forEach(...) जैसे इटरेटर्स के लिए टाइपिंग को गड़बड़ कर देता है जिसमें कभी भी undefined मान शामिल नहीं होंगे।

जब मैं someObject[someKey] करने के बाद अपरिभाषित की जांच नहीं करता, लेकिन Object.values(someObject).forEach(...) करते समय नहीं, तो मैं टाइपस्क्रिप्ट उत्पन्न त्रुटियों को देखना चाहता हूं।

@tobico https://github.com/microsoft/TypeScript/issues/13778#issuecomment -536248028

@danielnixon यह कोई समाधान नहीं है, यह एक समाधान है। समान उद्देश्यों के लिए भाषा के अंतर्निहित टूल का उपयोग करके आपको या किसी अन्य डेवलपर को गलती से (यदि आप इसे ऐसा भी कह सकते हैं) रोक नहीं सकते हैं। मेरा मतलब है, मैं इस सामान के लिए fp-ts का उपयोग करता हूं, लेकिन यह समस्या अभी भी मान्य है और इसे ठीक करने की आवश्यकता है।

जबकि मैं @RyanCavanaugh से विपरीत तर्कों का पालन कर सकता हूं:

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

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

1. सांख्यिकीय रूप से उन निर्माणों की पहचान करें जिनमें त्रुटि होने की संभावना है।

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

तकनीकी दृष्टिकोण से, निर्माण इस प्रकार हैं:

const x = ['a', 'b', 'c']
console.log(x[3]) // type: string, reality: undefined

टाइपस्क्रिप्ट का पहला लक्ष्य तोड़ता है। लेकिन ऐसा नहीं होता है यदि टाइपस्क्रिप्ट अधिक सटीक प्रकार जानता है:

const x = ['a', 'b', 'c'] as const
console.log(x[3]) // compile error: Tuple type 'readonly ["a", "b", "c"]' of length '3' has no element at index '3'.ts(2493)

व्यावहारिक दृष्टिकोण से, यह एक ट्रेड-ऑफ है yet । यह मुद्दा और कई बंद मुद्दों से पता चलता है कि इस बदलाव के लिए समुदाय की उच्च मांग है: एटीएम 238 अपवोटर्स बनाम 2 डाउनवॉटर। बेशक यह अफ़सोस की बात है कि लूप के लिए उपरोक्त "सही" प्रकार का अनुमान नहीं लगाता है, लेकिन ठीक है, मुझे पूरा यकीन है कि अधिकांश अपवॉटर ! और नए ? साथ रह सकते हैं ध्यान का संकेत और इसे सुरक्षित मामलों में मजबूर करें। लेकिन दूसरी तरफ "खतरनाक" पहुंच पर सही प्रकार प्राप्त करें।

चूंकि मैं मानता हूं कि यह बड़े कोड बेस के लिए एक बहुत ही संवेदनशील परिवर्तन है, इसलिए मैं एक कॉन्फ़िगरेशन प्रॉपर्टी के लिए वोट करता हूं, जैसा कि यहां प्रस्तावित किया गया था । कम से कम समुदाय से प्रतिक्रिया प्राप्त करने के लिए। यदि यह संभव नहीं है, तो ठीक है, TS 4.0 इसे प्राप्त करना चाहिए।

यह एक प्रस्तावित समाधान नहीं है, बल्कि सिर्फ एक प्रयोग है: मैंने अपने node_modules अंदर एक मौजूदा प्रोजेक्ट पर lib.es5.d.ts को संशोधित करने का प्रयास किया जो टाइपस्क्रिप्ट का उपयोग करता है यह देखने के लिए कि यह कैसा होगा यदि हमारे पास _did_ एक कंपाइलर है इसके लिए विकल्प। मैंने Array और ReadonlyArray संशोधित किया:

interface ReadonlyArray<T> {
  ...
  [n: number]: T | undefined; // was just T
}

interface Array<T> {
  ...
  [n: number]: T | undefined; // was just T
}

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

1. इससे न केवल हमारे कोडबेस में, बल्कि हमारी निर्भरता में से एक में टाइप त्रुटियां हुईं: io-ts। चूंकि io-ts आपको अपने कोड में उपयोग किए जाने वाले प्रकार बनाने की अनुमति देता है, मुझे नहीं लगता कि इस विकल्प को केवल अपने कोडबेस पर लागू करना संभव है और इसे io-ts के प्रकारों पर भी लागू नहीं करना है। इसका मतलब है कि आईओ-टीएस और शायद कुछ अन्य पुस्तकालयों को अभी भी इस विकल्प के साथ काम करने के लिए अद्यतन करना होगा, भले ही इसे केवल एक कंपाइलर विकल्प के रूप में पेश किया गया हो। पहले तो मैंने सोचा था कि इसे एक कंपाइलर विकल्प बनाने से यह कम विवादास्पद हो जाएगा, लेकिन यदि विकल्प का उपयोग करने वाले लोग असंगतताओं के बारे में विभिन्न पुस्तकालय लेखकों के समूह से शिकायत करना शुरू करते हैं, तो यह केवल टीएस 4.0 होने से भी अधिक विवादास्पद हो सकता है। ब्रेकिंग परिवर्तन।

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

3. मेरे पास for (let i = 0; i < array.length; i++) लूप के अंदर एक प्रकार की त्रुटि थी जो मनमाने ढंग से Array<T> पर लूपिंग कर रही थी। मैं केवल undefined जांच के लिए एक प्रकार का गार्ड नहीं जोड़ सका, क्योंकि T स्वयं undefined शामिल हो सकता है। एकमात्र समाधान जिसके बारे में मैं सोच सकता था कि ए) टाइप एरर या @ts-ignore टाइप एरर को शांत करने के लिए उपयोग करें या बी) इसके बजाय फॉर-ऑफ लूप का उपयोग करें। व्यक्तिगत रूप से मुझे यह बहुत बुरा नहीं लगता है (शायद कुछ ऐसे मामले हैं जहां किसी सरणी पर पुनरावृति करने के लिए फॉर-ऑफ़ लूप का उपयोग करना वैसे भी बेहतर नहीं है), लेकिन यह विवादास्पद हो सकता है।

4. ऐसे कई मामले हैं जहां मौजूदा कोड पहले से ही .length के मूल्य के बारे में कुछ दावा कर रहा था और फिर सरणी में एक तत्व तक पहुंच रहा था। ये अब .length चेक के बावजूद टाइप त्रुटियों का कारण बने, इसलिए मुझे .length चेक पर निर्भर न होने के लिए कोड बदलना पड़ा या केवल एक अनावश्यक !== undefined चेक जोड़ना पड़ा। यह वास्तव में अच्छा है, तो टाइपप्रति किसी तरह एक के उपयोग की अनुमति सकता है .length के लिए जरूरत से बचने के लिए जाँच !== undefined जांच। मुझे लगता है कि वास्तव में इसे लागू करना मामूली नहीं होगा, हालांकि।

5. जेनेरिक सरणी प्रकार के तत्वों के प्रकार को प्राप्त करने के लिए कुछ कोड A[number] का उपयोग कर रहे थे। हालांकि, यह अब केवल T बजाय T | undefined वापस आ गया है, जिससे कहीं और टाइप त्रुटियां हो रही हैं। मैंने इसके आसपास काम करने के लिए एक सहायक बनाया:

   type ArrayValueType<A extends { [n: number]: unknown }> = (
     A extends Array<infer T> ? T :
     A extends ReadonlyArray<infer T> ? T :
     A[number] // Fall back to old way of getting array element type
   );
   

   लेकिन यहां तक ​​​​कि इस सहायक के साथ संक्रमण को आसान बनाने के लिए, यह अभी भी एक बड़ा ब्रेकिंग परिवर्तन है। शायद इस समस्या से बचने के लिए टाइपस्क्रिप्ट में A[number] लिए किसी प्रकार का विशेष मामला हो सकता है, लेकिन यदि संभव हो तो अजीब विशेष मामलों से बचना अच्छा होगा।

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

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

@butchler मैंने इनमें से कुछ मुद्दों के माध्यम से भी भाग लिया है, मैंने something[i] को something(i) रूप में देखना शुरू कर दिया है, यानी, मैं केवल if (Meteor.user() && Meteor.user()._id) {...} जैसी किसी चीज़ का उपयोग नहीं कर सकता, इसलिए मैं नहीं करता' टी सरणी अनुक्रमण के लिए इस दृष्टिकोण की उम्मीद है; मुझे पहले वह मान प्राप्त करना होगा जिसे मैं सरणी से निरीक्षण करना चाहता हूं। मैं जो कहने की कोशिश कर रहा हूं वह यह है कि टीएस पर भरोसा करने के लिए यह समझने के लिए कि लंबाई की संपत्ति की जांच करना और उसके आधार पर कुछ दावा करना टाइप सिस्टम पर बहुत अधिक तनाव डाल सकता है। एक चीज जिसने मुझे संक्रमण से दूर कर दिया (इस तथ्य के अलावा कि कुछ अन्य पुस्तकालयों में भी त्रुटियां हैं, जैसा आपने कहा है) यह है कि सरणी विनाश अभी तक सही ढंग से काम नहीं कर रहा है और मूल्य नष्ट नहीं होगा T | undefined लेकिन T (मेरी अन्य टिप्पणी देखें)।
इसके अलावा, मुझे लगता है कि lib.es5.d.ts को ओवरराइड करना एक अच्छा तरीका है। भले ही भविष्य में चीजें बदल जाएंगी, परिवर्तन को वापस करने से अतिरिक्त त्रुटियां नहीं आएंगी, लेकिन यह सुनिश्चित होगा कि कुछ एज-केस पहले से ही कवर किए गए हैं।
हम पहले से ही उपयोग करने के लिए शुरू कर दिया है patch-package बदलाव के लिए में किसी प्रकार की परिभाषाएँ react और इस दृष्टिकोण काम ठीक लगता है।

मैं इनमें से कुछ मुद्दों से भी गुजरा हूं, मैंने कुछ [i] को कुछ (i) के रूप में देखना शुरू कर दिया है, यानी, मैं बस कुछ का उपयोग नहीं कर सकता जैसे if (Meteor.user() && Meteor.user()._id) { ...}, इसलिए मुझे सरणी अनुक्रमण के लिए इस दृष्टिकोण की अपेक्षा नहीं है; मुझे पहले वह मान प्राप्त करना होगा जिसे मैं सरणी से निरीक्षण करना चाहता हूं।

हाँ, जब मैं अपने प्रयोग की कोशिश कर रहा था तो मैंने भी इस दृष्टिकोण का उपयोग किया। उदाहरण के लिए, कोड जिसे पहले लिखा गया था:

if (array[i]) {
  array[i].doSomething(); // causes a type error with our modified Array types
}

कुछ इस तरह बदलना पड़ा:

const arrayValue = array[i]
if (arrayValue) {
  arrayValue.doSomething();
}

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

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

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

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

सरणियों को अनदेखा करना, और एक पल के लिए Record<string, T> पर ध्यान केंद्रित करना, मेरी व्यक्तिगत इच्छा सूची यह है कि लेखन केवल T अनुमति देता है लेकिन पढ़ना T|undefined हो सकता है।

declare const obj : Record<string, T>;
declare const t : T;
obj["k"] = t; //ok
obj["k"] = undefined; //error, undefined not assignable to T

//T|undefined inferred,
//since we don't know if "k2" is an "ownProperty" of obj
const v = obj["k2"];

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

//Shouldn't just be string[]
//Should also be something like (keyof valueof obj)[],
//A dependent type
const keys = Object.keys(obj);

सरणियों पर वापस जाने पर, समस्या यह है कि सरणियों के लिए सूचकांक हस्ताक्षर का इरादा समान नहीं है Record<number, T> ।

तो, आपको पूरी तरह से अलग निर्भर प्रकार के गार्ड की आवश्यकता होगी, जैसे,

for (let i=0; i<arr.length; ++i) {
  //i is not just number
  //i should also be something like keyof valueof arr 
}

तो, सरणियों के लिए अनुक्रमणिका हस्ताक्षर वास्तव में Record<number, T> । यह Record<(int & (0 <= i < this["length"]), T> (एक श्रेणी और संख्या-समर्थित पूर्णांक प्रकार) जैसा है

इसलिए, जबकि मूल पोस्ट केवल सरणियों के बारे में बात करती है, शीर्षक "बस" string या "बस" number सूचकांक हस्ताक्षर का सुझाव देता है। और वे दो पूरी तरह से अलग चर्चा कर रहे हैं।

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

यह देखते हुए कि forEach , map , filter , आदि जैसे कार्य मौजूद हैं (और IMHO अधिक बेहतर हैं), मैं TS टीम से अपने अनुमान इंजन को बहुत जटिल करने की उम्मीद नहीं करूंगा नियमित रूप से लूप के साथ एक सरणी पर लूपिंग का समर्थन करें। मुझे लगता है कि इसे पूरा करने की कोशिश करने से बहुत अधिक अप्रत्याशित जटिलता है। उदाहरण के लिए, चूंकि i स्थिर नहीं है, तो क्या होगा यदि कोई लूप के अंदर i का मान बदल देता है? निश्चित रूप से, यह एक बढ़त का मामला है, लेकिन यह कुछ ऐसा है जिसे उन्हें (उम्मीद से) सहज तरीके से संभालने की आवश्यकता है।

हालाँकि, इंडेक्स सिग्नेचर को ठीक करना अपेक्षाकृत सरल (ish) होना चाहिए, जैसा कि उपरोक्त टिप्पणियों ने दिखाया है।

4. ऐसे कई मामले हैं जहां मौजूदा कोड पहले से ही .length के मूल्य के बारे में कुछ दावा कर रहा था और फिर सरणी में एक तत्व तक पहुंच रहा था। ये अब .length चेक के बावजूद टाइप त्रुटियों का कारण बने, इसलिए मुझे .length चेक पर निर्भर न होने के लिए कोड बदलना पड़ा या केवल एक अनावश्यक !== undefined चेक जोड़ना पड़ा। यह वास्तव में अच्छा है, तो टाइपप्रति किसी तरह एक के उपयोग की अनुमति सकता है .length के लिए जरूरत से बचने के लिए जाँच !== undefined जांच। मुझे लगता है कि वास्तव में इसे लागू करना मामूली नहीं होगा, हालांकि।

@ कसाई
जिज्ञासा से, इनमें से कितने एक बदलते चर के साथ पहुंच रहे थे, बनाम एक निश्चित संख्या के साथ पहुंच रहे थे? क्योंकि, बाद के मामले में, आप संभवतः सरणी का उपयोग टुपल के रूप में कर रहे हैं, जिसके लिए TS सरणी लंबाई का ट्रैक रखता है। यदि आप अक्सर टुपल्स के रूप में सरणियों का उपयोग कर रहे हैं, तो मुझे उत्सुकता होगी कि वास्तविक टुपल्स के रूप में उन्हें फिर से टाइप करने से त्रुटियों की मात्रा क्या होती है।

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

मैंने एक मामले में भाग लिया जहां मैंने चर के प्रकार को टुपल में बदलने के लिए एक सरणी अक्षर में as const जोड़कर एक प्रकार की त्रुटि तय की। मुझे बिल्कुल पता नहीं है कि हमारे कोडबेस में यह कितना आम है, हालांकि, मैंने कई सौ में से केवल 10 त्रुटियों को ही देखा है।

मैंने आज इसके साथ एक मुद्दा भी मारा।
हम एक गणना सूचकांक के माध्यम से एक सरणी से पहुंच रहे हैं। वह सूचकांक सीमा से बाहर हो सकता है।
तो हमारे पास हमारे कोड में ऐसा कुछ है:

const noNext = !items[currentIndex + 1];

इसके परिणामस्वरूप noNext को false रूप में परिभाषित किया जा रहा है। क्या गलत है। यह सच हो सकता है।
मैं items को Array<Item | undefined> रूप में परिभाषित नहीं करना चाहता क्योंकि यह गलत अपेक्षा देता है।
यदि कोई अनुक्रमणिका है तो वह कभी भी undefined नहीं होनी चाहिए। लेकिन अगर आप गलत इंडेक्स का उपयोग कर रहे हैं, तो यह _is_ undefined ।
निश्चित रूप से, उपरोक्त को संभवतः .length चेक का उपयोग करके या noNext स्पष्ट रूप से boolean रूप में परिभाषित करके हल किया जा सकता है।
लेकिन अंत में यह कुछ ऐसा है जो मुझे तब से परेशान करता है जब से मैंने टाइपस्क्रिप्ट का उपयोग करना शुरू किया और मुझे कभी समझ नहीं आया कि | undefined डिफ़ॉल्ट रूप से शामिल क्यों नहीं है।

चूँकि मैं अधिकांश से टाइपस्क्रिप्ट-एस्लिंट का उपयोग करने की अपेक्षा करता हूँ, क्या कोई ऐसा नियम है जो यह लागू कर सकता है कि मूल्यों का उपयोग करने से पहले अनुक्रमण के बाद जाँच की जानी चाहिए? TS से समर्थन लागू होने से पहले यह मददगार हो सकता है।

मामले में यह किसी के हित में हो सकता है। पिछली टिप्पणी में मैंने उल्लेख किया था कि Array अनुक्रमण परिभाषा को lib.es5.d.ts में पैच करने के दृष्टिकोण में सरणी विनाशकारी पर कुछ अजीब व्यवहार है क्योंकि ऐसा लगता है कि यह परिवर्तन से प्रभावित नहीं था। ऐसा लगता है कि यह target में tsconfig.json विकल्प पर निर्भर करता है और यह es5 होने पर सही ढंग से काम करता है (https://github.com/microsoft/TypeScript/issues/37045 )

हमारे प्रोजेक्ट के लिए यह कोई समस्या नहीं है क्योंकि हम noEmit विकल्प का उपयोग कर रहे हैं और ट्रांसपिलेशन को meteor द्वारा नियंत्रित किया जाता है। लेकिन उन परियोजनाओं के लिए जहां यह एक समस्या हो सकती है, एक समाधान जो काम कर सकता है वह है safe-array-destructuring (https://github.com/typescript-eslint/typescript-eslint/pull/1645)।
यह अभी भी एक मसौदा है और यह तब मूल्यवान नहीं हो सकता है जब टाइपस्क्रिप्ट कंपाइलर में पूरा मुद्दा तय किया जाएगा, लेकिन अगर आपको लगता है कि यह उपयोगी हो सकता है, तो typescript-eslint नियम पीआर में किसी भी चिंता/सुधार को संबोधित करने के लिए स्वतंत्र महसूस करें

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

const example = (args: string[]) => {
  const [userID, nickname] = args
}

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

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

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

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

@caseyhoward जैसा कि पहले इस मुद्दे में उल्लेख किया गया है, यह विभिन्न Array.prototype कार्यों के साथ अवांछित व्यवहार का कारण बनता है:

x.forEach( (i: string) => { ... } )  // Error because i has type string | undefined

इसे array.prototype फ़ंक्शन में ठीक करने की आवश्यकता नहीं है। सरणी विनाशकारी के लिए यह एक बड़ा मुद्दा है!

इसमें आज फिर भाग गया। मुझे अभी भी लगता है कि सही समझौता यह है , जिस पर मुझे कुछ प्रतिक्रिया प्राप्त करना अच्छा लगेगा।

इस मुद्दे के लिए एक और उपयोग का मामला- टाइपस्क्रिप्ट-एस्लिन्ट का उपयोग करते समय और no-unnecessary-condition सक्षम करते समय मैं इस समस्या में भाग गया। अतीत में, उस इंडेक्स पर तत्व पर कुछ ऑपरेशन करने के लिए इंडेक्स द्वारा किसी सरणी तक पहुंचने पर, हम यह सुनिश्चित करने के लिए वैकल्पिक चेनिंग का उपयोग करते हैं कि इंडेक्स परिभाषित किया गया है (यदि इंडेक्स सीमा से बाहर है), जैसा कि array[i]?.doSomething() । इस मुद्दे में उल्लिखित समस्या के साथ, हालांकि, no-unnecessary-condition वैकल्पिक चेनिंग को अनावश्यक के रूप में चिह्नित करता है (जैसा कि टाइपस्क्रिप्ट के अनुसार प्रकार अशक्त नहीं है) और ऑटोफिक्स वैकल्पिक चेनिंग को हटा देता है, जिससे रनटाइम त्रुटियों की ओर जाता है जब सरणी का उपयोग होता है सूचकांक i वास्तव में अपरिभाषित है।

इस सुविधा के बिना अपने आवेदन बहुत गाड़ी के रूप में मैं बहु-आयामी सरणी के साथ काम कर रहा हूँ, मैं हमेशा खुद का उपयोग कर पहुँच तत्वों को याद दिलाने के लिए है बन गया xs[i]?.[j] के बजाय xs[i][j] , यह भी मैं स्पष्ट रूप से डाली करने के लिए है प्रकार की सुरक्षा सुनिश्चित करने के लिए const element = xs[i]?.[j] as Element | undefined जैसे एक्सेस किए गए तत्व।

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

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

सुनिश्चित नहीं हैं कि आपका क्या मतलब है क्या आप समस्या को जोड़ सकते हैं या उदाहरण दिखा सकते हैं?

बुधवार, 29 अप्रैल, 2020 को दोपहर 2:41 बजे किरिल ग्रोशकोव सूचनाएं @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-621096030 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAAGFJJT37N54I7EH2QLBYDRO7Y4NANCNFSM4C6KEKAA
.

@alangpierce

एक विचार जो ऐसा लगता है कि यह आशाजनक हो सकता है: क्या होगा यदि आप इंडेक्स हस्ताक्षर को परिभाषित करते समय ?: उपयोग कर सकते हैं यह इंगित करने के लिए कि आप सामान्य उपयोग के तहत कभी-कभी मूल्यों के गायब होने की उम्मीद करते हैं? यह ऊपर वर्णित | undefined तरह कार्य करेगा, लेकिन अजीब डाउनसाइड्स के बिना। इसे स्पष्ट undefined मानों को अस्वीकार करने की आवश्यकता होगी, जो मुझे लगता है कि सामान्य ?: से एक अंतर है।

यह एक दिलचस्प विचार है जो सही दिशा में इंगित करता है। हालांकि, मैं तर्क को उलट दूंगा: डिफ़ॉल्ट मामला यह होना चाहिए कि इंडेक्स हस्ताक्षर में | undefined । यदि आप संकलक को बताना चाहते हैं कि अपरिभाषित मामला आपके कोड में कभी नहीं हो सकता है (इसलिए आप कभी भी अमान्य कुंजियों तक नहीं पहुंच सकते हैं), तो आप हस्ताक्षर में !: जोड़ सकते हैं, जैसे:

type AlwaysDefined = {[key: string]!: string};
const t: AlwaysDefined = {};

t['foo'] // Has type string

और !: बिना डिफ़ॉल्ट मामला ऐसा लगेगा जैसे हम इसे जानते हैं, लेकिन यह सुरक्षित होगा:

type MaybeUndefined = {[key: string]: string};
const t: MaybeUndefined = {};

t['foo'] // Has type string | undefined

इस तरह आपके पास डिफ़ॉल्ट रूप से सुरक्षा है और उसी तरह आपको स्पष्ट रूप से undefined शामिल करने की आवश्यकता नहीं है जो दुर्घटना से undefined लिखने की अनुमति देगा।

क्षमा करें यदि यह पहले से ही सुझाया गया था, तो मैं इस सूत्र में सभी टिप्पणियों को नहीं पढ़ सका।

सामान्य तौर पर, मुझे वास्तव में लगता है कि अब हमारे पास जो डिफ़ॉल्ट व्यवहार है, वह वह नहीं है जो उपयोगकर्ता टाइपस्क्रिप्ट का उपयोग करते समय अपेक्षा करते हैं। सॉरी की तुलना में सुरक्षित रहना बेहतर है, खासकर जब कंपाइलर द्वारा किसी त्रुटि को आसानी से पकड़ा जा सकता है।

मैं अपने प्रोजेक्ट के साथ काम करने के लिए index.d.ts नहीं प्राप्त कर सका और वास्तव में इससे निपटना नहीं चाहता था।

मैंने यह छोटा हैक बनाया है जो एक प्रकार के गार्ड को मजबूर करता है:

 const firstNode = +!undefined && nodes[0];

हालांकि प्रकार समाप्त होता है: 0 | T , यह अभी भी काम करता है।

const firstNode = nodes?.[0] काम नहीं करेगा?

@ricklove किसी भी कारण से आपने +!undefined को केवल 1 ?

const firstNode = nodes?.[0] काम नहीं करेगा?

नहीं, जैसा कि टाइपस्क्रिप्ट (गलत तरीके से, मेरी राय में) इसे वैकल्पिक नहीं मानेगा (देखें #35139)।

फ्लो के दस्तावेज़ीकरण के अनुसार इंडेक्स सिग्नेचर के साथ व्यवहार वर्तमान में टाइपस्क्रिप्ट के समान है:

जब किसी ऑब्जेक्ट प्रकार में इंडेक्सर प्रॉपर्टी होती है, तो प्रॉपर्टी एक्सेस को एनोटेट प्रकार माना जाता है, भले ही ऑब्जेक्ट में रनटाइम पर उस स्लॉट में कोई मान न हो। यह सुनिश्चित करने के लिए प्रोग्रामर की जिम्मेदारी है कि एक्सेस सुरक्षित है, जैसे कि सरणियों के साथ।

var obj: { [number]: string } = {};
obj[42].length; // No type error, but will throw at runtime

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

TS का एक फायदा होगा यदि संकलक उपयोगकर्ताओं को इस प्रकार की बग बनाने से रोकता है। इस सूत्र में सभी टिप्पणियों को पढ़कर, ऐसा लगता है कि यहां के विशाल बहुमत को यह सुविधा पसंद आएगी। क्या TS टीम अभी भी इसके खिलाफ 100% है?

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

[#38470 से यहां पर चल रही चर्चा]
सभी तर्कों को स्वीकार करना कि यह सरणी के लिए व्यावहारिक क्यों नहीं होगा ..
मुझे लगता है कि इसे निश्चित रूप से टुपल्स के लिए संबोधित किया जाना चाहिए:

// tuple 
var str = '';
var num = 100
var aa = [str, num] as const

// Awesome
var shouldBeString = aa[0] // string
var shouldBeNumber = aa[1] // number
var shouldError = aa[10000]; // type error

// Not so awesome 
var foo = aa[num] // string | number

foo string | number | undefined क्यों नहीं बनाते?

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

इनसे भी मदद मिल सकती है

var notString1 = aa[Infinity]; // no error, not undefined
var notString2 = aa[NaN]; // no error, not undefined

जो मूल रूप से मेरी रनटाइम त्रुटि के कारण होता है के रूप में एक number बन गया एक NaN , तो लौट आए एक undefined एक टपल से ..
जिनमें से सभी प्रकार से सुरक्षित थे

मुझे यकीन नहीं है कि टुपल्स वास्तव में इतने अलग हैं। उन्हें बाकी प्रकारों (जैसे [str, ...num[]] ) को समायोजित करना होगा, और तकनीकी रूप से aa[Infinity] पूरी तरह से मान्य जावास्क्रिप्ट है, इसलिए मैं देख सकता था कि उनके लिए एक विशेष मामला बनाना जटिल हो रहा है।

आपकी पोस्ट ने मुझे यह सोचने पर मजबूर कर दिया कि अगर हमें इंडेक्स-रिटर्न को अपरिभाषित मानने के लिए कुछ समर्थन मिलता तो यह कैसा दिखता। यदि, आपके उदाहरण के अनुसार, aa[num] वास्तव में string | number | undefined रूप में टाइप किया था, तो क्या मुझे for (let i = 0; i < 2; i++) { foo(aa[i]!); } लिखना होगा, हालांकि मुझे पता है कि सूचकांक सीमा में रहेगा? मेरे लिए, जब सख्त अशक्त चेक मेरे द्वारा लिखी गई किसी चीज़ को फ़्लैग करता है, तो मैं इसे ठीक करने में सक्षम होना पसंद करता हूँ या तो चीजों को पहले स्थान पर बेहतर तरीके से टाइप करके, या रनटाइम गार्ड का उपयोग करके - अगर मुझे एक गैर-शून्य अभिकथन का सहारा लेना है, तो मैं आम तौर पर इसे मेरी ओर से विफलता के रूप में देखें। हालाँकि, मुझे इस मामले में इसके आसपास कोई रास्ता नहीं दिख रहा है, और यह मुझे परेशान करता है।

यदि tuple[number] हमेशा T | undefined टाइप किया जाता है, तो आप उस मामले को कैसे संभालना चाहेंगे जहां आप जानते हैं कि अनुक्रमणिका सही ढंग से बंधी हुई है?

@ thw0rted मुझे याद नहीं आ रहा है कि पिछली बार मैंने for लूप का उपयोग कब किया था ( .map और .reduce ftw)। इसलिए इसके लिए एक कंपाइलर विकल्प बहुत अच्छा होगा (जो डिफ़ॉल्ट रूप से बंद हो सकता है)। कई परियोजनाओं को कभी भी आपके द्वारा प्रदान किए गए मामले की तरह कुछ भी नहीं मिलता है, और केवल सरणी विनाश आदि के लिए अनुक्रमणिका हस्ताक्षर का उपयोग करें।

(मेरी मूल टिप्पणी: https://github.com/microsoft/TypeScript/issues/13778#issuecomment-517759210)

ओह सभी ईमानदारी में, मैं भी शायद ही कभी फॉर-लूप के साथ इंडेक्स करता हूं। मैं Object.entries या Array#map व्यापक उपयोग करता हूं, लेकिन हर बार एक समय में मुझे किसी ऑब्जेक्ट में इंडेक्स करने के लिए कुंजियों को पास करने की आवश्यकता होती है या (शायद कम अक्सर अभी भी) इंडेक्स को एक सरणी या टपल में। for लूप निश्चित रूप से एक काल्पनिक उदाहरण था, लेकिन यह इस बिंदु को उठाता है कि या तो विकल्प ( undefined या नहीं) में कमियां हैं।

लेकिन यह इस बात को बढ़ाता है कि या तो विकल्प ( undefined या नहीं) में कमियां हैं।

हाँ और यह अच्छा होगा यदि टाइपस्क्रिप्ट का उपयोगकर्ता चुन सकता है कि वे किस नकारात्मक पक्ष को पसंद करते हैं: पलक:

ओह सभी ईमानदारी में, मैं भी शायद ही कभी फॉर-लूप के साथ इंडेक्स करता हूं। मैं Object.entries या Array#map व्यापक उपयोग करता हूं, लेकिन हर बार एक समय में मुझे किसी ऑब्जेक्ट में इंडेक्स करने के लिए कुंजियों को पास करने की आवश्यकता होती है या (शायद कम अक्सर अभी भी) इंडेक्स को एक सरणी या टपल में।

उन मामलों में जहां आपको इसकी आवश्यकता है, आप Array#entries उपयोग कर सकते हैं:

for (const [index, foo] of array.entries()) {
    bar(index, foo)
}

मैं व्यक्तिगत रूप से Array#forEach का इतना अधिक उपयोग नहीं करता, और मैं पुनरावृत्ति के लिए Array#map का कभी भी उपयोग नहीं करता (हालांकि मैं इसे मैपिंग के लिए हर समय उपयोग करता हूं)। मैं अपना कोड फ्लैट रखना पसंद करता हूं, और मैं लूप के लिए ... से बाहर निकलने की क्षमता की सराहना करता हूं।

मुझे यकीन नहीं है कि टुपल्स वास्तव में इतने अलग हैं। उन्हें बाकी प्रकारों (जैसे [str, ...num[]] ) को समायोजित करना होगा, और तकनीकी रूप से aa[Infinity] पूरी तरह से मान्य जावास्क्रिप्ट है, इसलिए मैं देख सकता था कि उनके लिए एक विशेष मामला बनाना जटिल हो रहा है।

आपकी पोस्ट ने मुझे यह सोचने पर मजबूर कर दिया कि अगर हमें इंडेक्स-रिटर्न को अपरिभाषित मानने के लिए कुछ समर्थन मिलता तो यह कैसा दिखता। यदि, आपके उदाहरण के अनुसार, aa[num] वास्तव में string | number | undefined रूप में टाइप किया था, तो क्या मुझे for (let i = 0; i < 2; i++) { foo(aa[i]!); } लिखना होगा, हालांकि मुझे पता है कि सूचकांक सीमा में रहेगा? मेरे लिए, जब सख्त अशक्त चेक मेरे द्वारा लिखी गई किसी चीज़ को फ़्लैग करता है, तो मैं इसे ठीक करने में सक्षम होना पसंद करता हूँ या तो चीजों को पहले स्थान पर बेहतर तरीके से टाइप करके, या रनटाइम गार्ड का उपयोग करके - अगर मुझे एक गैर-शून्य अभिकथन का सहारा लेना है, तो मैं आम तौर पर इसे मेरी ओर से विफलता के रूप में देखें। हालाँकि, मुझे इस मामले में इसके आसपास कोई रास्ता नहीं दिख रहा है, और यह मुझे परेशान करता है।

यदि tuple[number] हमेशा T | undefined टाइप किया जाता है, तो आप उस मामले को कैसे संभालना चाहेंगे जहां आप जानते हैं कि अनुक्रमणिका सही ढंग से बंधी हुई है?

मुझे यकीन नहीं है कि टुपल्स पर इतना अधिक for(let i..) पुनरावृत्ति हो रहा है ..
यदि टपल का एक ही प्रकार है तो उपयोगकर्ता एक ऐरे का उपयोग करने की जांच करेगा,

मेरे अनुभव में मिश्रित प्रकार के लिए टुपल्स बहुत अच्छे हैं और यदि यह सामान्य मामला है तो आप वैसे भी जांच कर रहे हैं

var str = '';
var num = 100
var aa = [str, num] as const
for (let i = 0; i < aa.length; i++) {
 aa[i] // needs some type check anyway to determine if 'string' or 'number'
}

यह भी मानते हुए कि यह प्रस्तावित परिवर्तन होता है, लोगों को ऐसा करने से क्या रोक रहा है?

// this sucks
for (let i = 0; i < 2; i++) { 
   foo(aa[i]!); // ! required
}

// this would work
for (let i = 0 as 0 | 1; i < 2; i++) { 
   foo(aa[i]); //  ! not required 
}

आप इस्तेमाल कर सकते हैं keyof typeof aa के बजाय 0 | 1 जब वे ठीक इस मुद्दे

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

मुझे लगता है कि ?? और ?. ऑपरेटरों के होने का मतलब है कि Array s तक रैंडम एक्सेस करना अब अधिक बोझिल नहीं है ।
लेकिन साथ ही, यह शायद कहीं अधिक सामान्य है

• पुनरावृति (उदाहरण के लिए .map या .forEach , जहां " T | undefined " की कोई आवश्यकता नहीं है, कॉलबैक कभी भी आउट-ऑफ-बाउंड इंडेक्स पर नहीं चलाया जाता है) या
• लूप में Array को पार करें, जिनमें से कुछ को स्थिर रूप से सुरक्षित होने के लिए निर्धारित किया जा सकता है ( for...of .. लगभग, _sparse arrays_ को छोड़कर, for...in मेरा मानना ​​​​है कि सुरक्षित है)।

और साथ ही, एक चर को "सुरक्षित अनुक्रमणिका" माना जा सकता है यदि इसे पहले <index> in <array> चेक किया जाता है।

_Clarification_: मैं Array<T> के मूल कारण के बारे में बात कर रहा हूं जिसमें इंडेक्स प्रकार [number]: T | undefined (लेकिन इसके बजाय सिर्फ [number]: T ), जो कि यह उपयोग करने के लिए बहुत बोझिल होगा।
मेरा मतलब है कि अब ऐसा नहीं है, इसलिए undefined जोड़ा जा सकता है।

@ vp2177 समस्या विशेषताएं नहीं हैं (हां, ?. काम करता है), समस्या यह है कि संकलक हमें इसके बारे में चेतावनी नहीं दे रहा है और खुद को पैर में गोली मारने से रोक रहा है।

हो सकता है कि एक लाइनिंग नियम ऐसा कर सकता है, लेकिन फिर भी।

हाँ, ?. काम करता है

क्षमा करें मैं असहमत हूं। ?. अनुक्रमित मूल्य पर गुणों तक पहुँचने के लिए काम करेगा, लेकिन संकलक अभी भी कहेगा कि मूल्य परिभाषित किया गया है चाहे वह है या नहीं (देखें #35139)।

इसमें जोड़ने के लिए, यदि आप एस्लिंट का उपयोग करते हैं और no-unnecessary-condition का उपयोग करना चाहते हैं, तो इस तरह के एक्सेस को अनावश्यक के रूप में चिह्नित किया जाएगा और हटा दिया जाएगा क्योंकि कंपाइलर का कहना है कि यह कभी भी अपरिभाषित नहीं होता है और इससे ?. अनावश्यक हो जाएगा।

@martpie क्षमा करें, मुझे लगता है कि आपने मेरी टिप्पणी को गलत समझा, एक स्पष्टीकरण जोड़ा।

मेरा मतलब है... ऐसा लगता है कि एक --strictIndexChecks या ऐसा ही एक अच्छा विचार है जो लोगों को इस प्रकार के व्यवहार को चुनने की अनुमति देता है। यह तब सभी के लिए एक ब्रेकिंग बदलाव नहीं होगा और यह अधिक सख्त प्रकार का वातावरण देता है।

मेरा मानना ​​है कि Flow इंडेक्स के लिए डिफ़ॉल्ट रूप से इस तरह से काम करता है और इसमें उपरोक्त मुद्दे नहीं हैं, लेकिन जब से मैंने इसका इस्तेमाल किया है, तब से कुछ समय हो गया है, इसलिए मुझसे गलती हो सकती है।

@bradennapier Flow इंडेक्स हस्ताक्षर में Array s के लिए T | undefined उपयोग नहीं करता है (दुर्भाग्य से टाइपस्क्रिप्ट के समान।)

मैंने पहले एक ऐसा तरीका सुझाया है जो हर किसी को खुश कर सकता है। आशा है कि इसे दूसरे शब्दों में दोहराना ठीक है।

मूल रूप से सूचकांक हस्ताक्षर का डिफ़ॉल्ट व्यवहार बदल जाएगा

• किसी सरणी या वस्तु से पढ़ते समय | undefined शामिल करें
• लिखते समय | undefined शामिल न करें (क्योंकि हम अपनी वस्तु में केवल T मान चाहते हैं)

परिभाषा इस प्रकार होगी:

type MaybeUndefined = {[key: string]: string};
const t: MaybeUndefined = {};

const x = t['foo'] // Has type string | undefined
t['foo'] = undefined // ERROR! 
t['foo'] = "test" // Ok

जो लोग इस प्रकार में undefined शामिल नहीं करना चाहते हैं, वे या तो इसे कंपाइलर विकल्प का उपयोग करके अक्षम कर सकते हैं या ! ऑपरेटर का उपयोग करके इसे केवल कुछ प्रकारों के लिए अक्षम कर सकते हैं:

type AlwaysDefined = {[key: string]!: string};
const t: AlwaysDefined = {};

const x = t['foo'] // Has type string
t['foo'] = undefined // ERROR! 
t['foo'] = "test" // Ok

मौजूदा कोड को तोड़ने के लिए, एक नया कंपाइलर विकल्प पेश करना भी बेहतर हो सकता है जो undefined को शामिल करने का कारण बनता है (जैसा कि ऊपर MaybeUndefined प्रकार के साथ दिखाया गया है)। यदि वह विकल्प निर्दिष्ट नहीं है, तो सभी अनुक्रमणिका हस्ताक्षर प्रकार ऐसा व्यवहार करते हैं मानो ! ऑपरेटर का उपयोग घोषणा के भीतर किया गया हो।

एक और विचार जो सामने आता है: कोड में कुछ स्थानों पर दो अलग-अलग व्यवहारों के साथ एक ही प्रकार का उपयोग करना चाह सकता है ( undefined या नहीं)। एक नया प्रकार मानचित्रण परिभाषित किया जा सकता है:

type MakeDefined<T> = {[K in keyof T]!: T[K]}

क्या यह टाइपस्क्रिप्ट का अच्छा विस्तार होगा?

मुझे यह विचार पसंद है लेकिन मुझे संदेह है कि हमें पहले https://github.com/microsoft/TypeScript/issues/2521 प्राप्त करना होगा - जो मुझे गलत नहीं लगता, मुझे अभी भी विश्वास है कि हमें बिल्कुल चाहिए , लेकिन मैं ' मैं अपनी सांस नहीं रोक रहा हूँ।

@bradennapier Flow इंडेक्स हस्ताक्षर में Array s के लिए T | undefined उपयोग नहीं करता है (दुर्भाग्य से टाइपस्क्रिप्ट के समान।)

हम्म ऑब्जेक्ट इंडेक्स के बारे में क्या? मैंने कभी भी सरणियों की आवश्यकता में भाग नहीं लिया है, लेकिन निश्चित रूप से यह आपको वस्तुओं का उपयोग करते समय जांचता है।

@bradennapier ऑब्जेक्ट इंडेक्स? जैसा कि, o[4] जहां o टाइप है object ? टाइपस्क्रिप्ट आपको ऐसा करने की अनुमति नहीं देता...

प्रकार '4' की अभिव्यक्ति का उपयोग '{}' प्रकार को अनुक्रमित करने के लिए नहीं किया जा सकता है
संपत्ति '4' प्रकार '{}'.ts(7053) पर मौजूद नहीं है

@RDGthree सभी चीजों के Microsoft के लिए श्वेत शूरवीर नहीं होना चाहिए, लेकिन आपने स्पष्ट रूप से पहले उत्तर में मेहेगाज़ी से इस बिट को याद किया:

सख्त नलचेक के अपवाद के साथ, हमारे पास ऐसे झंडे नहीं हैं जो सिस्टम व्यवहार के प्रकार को बदलते हैं। झंडे आमतौर पर त्रुटि रिपोर्टिंग को सक्षम/अक्षम करते हैं।

और थोड़ी देर बाद रयान कैवानुघ पर है:

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

तो मूल रूप से - वे इस तथ्य से पूरी तरह अवगत हैं कि एक ध्वज के लिए कहा जा रहा है, और अब तक वे आश्वस्त नहीं हुए हैं कि यह उनके लिए काम के लायक है बल्कि संदिग्ध लाभ के लिए सुझाव दिया गया है कि लोगों को इससे मिलेगा। ईमानदारी से कहूं तो मुझे कोई आश्चर्य नहीं है, क्योंकि हर कोई यहां बिल्कुल वही सुझाव और उदाहरण लेकर आता है जो पहले ही संबोधित किए जा चुके थे। आदर्श रूप से, आपको केवल for of या सरणियों के लिए विधियों का उपयोग करना चाहिए, और वस्तुओं के बजाय Map (या कम प्रभावी रूप से, 'टी | अपरिभाषित' ऑब्जेक्ट मान)।

मैं यहां इसलिए हूं क्योंकि मैं एक लोकप्रिय डीटी पैकेज बनाए रखता हूं और लोग |undefined को http हेडर मैप्स जैसी चीजों में जोड़ने के लिए कहते रहते हैं, जो पूरी तरह से उचित है, उस बिट को छोड़कर जहां यह हर मौजूदा उपयोग को तोड़ देगा , और तथ्य यह है कि यह Object.entries() जैसे अन्य सुरक्षित उपयोगों को उपयोग करने के लिए बहुत खराब बनाता है। टाइपस्क्रिप्ट के रचनाकारों की तुलना में आपकी राय बेहतर कैसे है, इस बारे में शिकायत करने के अलावा, यहां आपका वास्तव में क्या योगदान है?

साइमन, हो सकता है कि मैंने आपकी टिप्पणी को गलत तरीके से पढ़ा हो, लेकिन यह मूल सुझाव के पक्ष में एक तर्क की तरह लगता है। "आखिरी मील" लापता क्षमता संदर्भ के आधार पर संपत्तियों को | undefined कभी-कभी मानने की है, लेकिन अन्य मामलों में नहीं। इसलिए मैंने #2521 अपथ्रेड के लिए एक सादृश्य बनाया।

एक आदर्श परिदृश्य में, मैं एक सरणी या वस्तु घोषित कर सकता हूं जैसे कि, दिया गया

ts const arr: Array<T>; const n: number; const obj: {[k: K]: V}; const k: K;

मैं किसी भी तरह से समाप्त कर सकता हूँ

• arr[n] प्रकार T | undefined
• arr[n] = undefined एक त्रुटि है
• मेरे पास arr पर किसी प्रकार के पुनरावृत्ति तक पहुंच है जो मुझे T रूप में टाइप किए गए मान देता है, न कि T | undefined
• obj[k] प्रकार V | undefined
• obj[k] = undefined एक त्रुटि है
• उदाहरण के लिए Object.entries() मुझे [K, V] टुपल्स देना चाहिए और कुछ भी अपरिभाषित नहीं किया जा सकता है

यह समस्या की असममित प्रकृति है जो मेरे विचार में इस मुद्दे को परिभाषित करती है।

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

const example = (args: string[]) => {
  const [userID, duration, ...reason] = args
  // userID and duration is AUTOMATICALLy inferred to be a string here. 
 // However, if for whatever reason args is an empty array 
// userID is actually `undefined` and NOT a `string`. 

// This is valid but it should not be because userID could be undefined
userID.toUpperCase()
}

मैं इस मुद्दे के मूल बिंदु से बहुत दूर नहीं जाना चाहता, लेकिन आपको फ़ंक्शन तर्क के लिए टपल प्रकार का उपयोग करके वास्तव में उस उदाहरण विधि की घोषणा करनी चाहिए। यदि फ़ंक्शन को ([userId, duration, ...reason]: [string, number, ...string[]]) => {} रूप में घोषित किया गया था तो आपको इसके बारे में पहली बार चिंता करने की आवश्यकता नहीं होगी।

मेरा मतलब है कि मैं इसे अभी कास्ट कर सकता हूं लेकिन यह वास्तव में कोई समाधान नहीं है। इसी तरह, यहां कोई भी केवल लूप सरणी अनुक्रमण के लिए कास्ट कर सकता है और साथ ही इस पूरे मुद्दे को म्यूट कर सकता है।

for (let i = 0; i < array.length; i++) {
  const value = array[i] as string | undefined
}

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

const example = (args: [string | undefined, string | undefined, ...string[] | ...undefined[]]) => {

}

यह बिल्कुल भी अच्छा नहीं है। लेकिन जैसा कि मैंने मुख्य मुद्दे के ऊपर कहा है, इसे इस तरह टाइप करने की भी आवश्यकता नहीं है, यह कि TS इसके लिए बिल्कुल भी चेतावनी नहीं देता है। यह उन देवों की ओर जाता है जो कोड को पुश करने के लिए इसे भूल जाते हैं, कूल सीआई को टीएससी विलय और तैनाती पर कोई समस्या नहीं मिली। TS कोड में आत्मविश्वास की भावना देता है और गलत टाइपिंग प्रदान करने से आत्मविश्वास का झूठा अहसास होता है। => रनटाइम पर त्रुटियाँ!

यह "कास्ट" नहीं है, जो आपके औपचारिक पैरामीटर को ठीक से टाइप कर रहा है। मेरा कहना था कि यदि आप अपनी विधि को सही ढंग से टाइप करते हैं, तो कोई भी जो इसे पुराने हस्ताक्षर ( args: string[] ) के साथ असुरक्षित रूप से कॉल कर रहा था, अब संकलन-समय पर त्रुटियां प्राप्त करेगा, जैसा कि उन्हें चाहिए , जब उनकी गारंटी नहीं है तर्कों की सही संख्या पास करें। यदि आप चाहते हैं कि लोगों को आपकी ज़रूरत के सभी तर्कों को पारित करने में विफल रहने और रन-टाइम पर स्वयं उनकी जाँच करने में विफल रहने दें, तो वास्तव में (args: [string?, number?, ...string[]]) रूप में लिखना बहुत आसान है। यह पहले से ही बहुत अच्छा काम करता है और वास्तव में इस मुद्दे से संबंधित नहीं है।

यह समस्या को उस फ़ंक्शन से दूसरे फ़ंक्शन में ले जाएगा जो इस फ़ंक्शन को कॉल कर रहा है। जैसा कि आपको अभी भी उपयोगकर्ताओं द्वारा प्रदान की गई स्ट्रिंग को अलग-अलग मानों में पार्स करने की आवश्यकता है और यदि आप कमांडहैंडलर के अंदर इसे पार्स करने के लिए सरणी विनाशकारी का उपयोग करते हैं जो इस फ़ंक्शन को कॉल करता है तो आप उसी समस्या के साथ समाप्त होते हैं।

Array Destructuring के लिए गलत टाइपिंग प्रदान करने का कोई तरीका नहीं है।

मैं इस मुद्दे के मूल बिंदु से बहुत दूर नहीं जाना चाहता

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

इस मुद्दे के साथ मेरी कुछ निराशाओं को | undefined को उस प्रकार पर लागू करने के लिए कुछ सरल वाक्यविन्यास द्वारा हल किया जाएगा जो अन्यथा ऑब्जेक्ट एक्सेस से अनुमानित होगा। जैसे:

const complexObject: { [key: string]: ComplexType } = { ... };
const maybeKey = 'two';

// From:
const maybeValue = complexObject[maybeKey] as
  | (Some<Complex<Type>> & Pick<WithPlentyOf, 'Utility'> & Types)
  | undefined;

// To:
const maybeValue2 = complexObject[maybeKey] as ?;

इसलिए सख्त टाइप-चेकिंग ऑप्ट-इन रहती है। नीचे काम करता है लेकिन दोहराव की आवश्यकता होती है (और जल्दी से समान मात्रा में दृश्य शोर जोड़ता है):

const maybeValue2 = complexObject[maybeKey] as
  | typeof complexObject[typeof maybeKey]
  | undefined;

मुझे लगता है कि इस तरह का "टाइप एस्टर टू हो सकता है" सिंटैक्स ( as ? ) require-safe-index-signature-access एस्लिंट नियम को लागू करना भी आसान बना देगा जो नए उपयोगकर्ताओं के लिए बहुत भ्रमित नहीं है। (उदाहरण के लिए "आप अंत में as ? जोड़कर लिंट त्रुटि को ठीक कर सकते हैं।") नियम में एक सुरक्षित ऑटोफिक्सर भी शामिल हो सकता है क्योंकि यह केवल संकलन को तोड़ने का कारण बन सकता है, रनटाइम समस्याओं को कभी नहीं।

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

मुझे नहीं लगता कि इस सरप्राइज टीएस फीचर से अलग इसका एक भी आवेदन है, हालांकि हे

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

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

एक अन्य सिंटैक्स विकल्प (जो ऊपर दिए गए as ? से कम उपयोग-मामला विशिष्ट होगा) infer कीवर्ड के उपयोग की अनुमति देने के लिए हो सकता है अन्यथा-अनुमानित प्रकार के लिए प्लेसहोल्डर के रूप में टाइप करें, उदाहरण:

const maybeValue = complexObject[maybeKey] as infer | undefined;

वर्तमान में infer घोषणाओं की अनुमति केवल सशर्त प्रकार ( ts(1338) ) के extends खंड में है, इसलिए infer कीवर्ड को as [...] के संदर्भ में एक अर्थ देना

अन्य मामलों के लिए पर्याप्त सामान्य होने के दौरान एस्लिंट नियम के माध्यम से infer | undefined का उपयोग करके लागू करना अभी भी उचित हो सकता है, उदाहरण के लिए जहां परिणामी प्रकार को उपयोगिता प्रकारों के साथ परिष्कृत किया जा सकता है:

// Strange example, maybe from an unusual compiler originally written in JS:
if(someRegularExpression.test(maybeKey)) {
  /**
  * If we are inside this code block and this `maybeKey` exists on `partialObject`, 
  * we know its `regexSuccess` must also be defined, though this knowledge 
  * cannot be encoded using TypeScript's type system.
  */
  const maybeValue = partialObject[maybeKey] as (Required<Pick<infer, 'regexSuccess'>> & infer) | undefined;
  // ...
}
// Here we don't know if `regexSuccess` is defined on `maybeValue2`:
const maybevalue2 = partialObject[maybeKey] as infer | undefined;

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

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

हमारा वर्तमान व्यवहार यह है कि टाइप एक्सप्रेशन Array<string>[number] की व्याख्या इस प्रकार की जाती है "वह प्रकार जो तब होता है जब आप किसी सरणी को किसी संख्या से अनुक्रमित करते हैं"। आपको लिखने की अनुमति है

const t: Array<string>[number] = "hello";

const t: string लिखने के गोल चक्कर के रूप में।

अगर यह झंडा होता तो क्या होता?

यदि Array<string>[number] string | undefined , तो आपके पास लिखने पर एक सुदृढ़ता समस्या है:

function write<T extends Array<unknown>>(arr: T, v: T[number]) {
    arr[0] = v;
}
const arr = ["a", "b", "c"];
// Would be OK
write(arr, undefined);

यदि Array<string>[number] string , तो आपके पास वही समस्या है जैसा कि पढ़ने पर वर्णित किया जा रहा है:

function read<T extends Array<unknown>>(arr: T): T[number] {
    return arr[14];
}
const arr = ["a", "b", "c"];
// Would be OK
const k: string = read(arr);

यह "इंडेक्स रीड टाइप" और "इंडेक्स राइट टाइप" दोनों के लिए टाइप सिंटैक्स जोड़ने के लिए ओवरकॉम्प्लेक्स लगता है। विचार?

मुझे यह जोड़ना चाहिए कि Array<string>[number] का अर्थ बदलना वास्तव में समस्याग्रस्त है क्योंकि इसका अर्थ यह होगा कि यह ध्वज घोषणा फाइलों की व्याख्या को बदल देता है। यह नर्वस करने वाला है क्योंकि यह उस तरह के झंडे की तरह लगता है जिसे पर्याप्त संख्या में लोग सक्षम करेंगे, लेकिन निश्चित रूप से टाइप की गई चीजों में त्रुटियां हो सकती हैं / नहीं हो सकती हैं, इसलिए हमें शायद यह सुनिश्चित करना होगा कि सब कुछ बनाता है दोनों दिशाओं में सफाई से। इस व्यवहार के साथ हम जितने झंडे जोड़ सकते हैं, वह स्पष्ट रूप से बहुत कम है (हम हर प्रकार के पैकेज के 64 अलग-अलग कॉन्फ़िगरेशन का परीक्षण नहीं कर सकते हैं) इसलिए मुझे लगता है कि हमें Array<T>[number] को T रूप में छोड़ना होगा।

@RyanCavanaugh आपके उदाहरण में write(arr, undefined) , write कॉल स्वीकार किया जाएगा, लेकिन असाइनमेंट arr[0] = v; अब संकलित नहीं होगा?

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

साथ ही, जबकि मुझे अपने सिर के ऊपर से कोई ठोस उदाहरण नहीं मिल रहा है, मुझे अपने ऐप को संकलित करने के लिए निश्चित रूप से skipLibCheck सेट करना पड़ा है। जब भी कोई नया TS रेपो बनाते हैं, तो यह हमारे बॉयलरप्लेट में एक मानक tsconfig विकल्प होता है, क्योंकि हमारे पास इसके साथ बहुत सारे मुद्दे हैं।

व्यक्तिगत रूप से (और शायद स्वार्थी रूप से), मैं किनारे के मामलों पर हिट ले रहा हूं, अगर यह _my_ कोड को आम तौर पर सुरक्षित बनाता है। मुझे अभी भी विश्वास है कि मैं अन्य किनारे के मामलों में चलने की तुलना में अधिक बार इंडेक्स द्वारा सरणी तक पहुंचने से शून्य पॉइंटर्स में चलाऊंगा, हालांकि मुझे अन्यथा आश्वस्त किया जा सकता है।

अगर सरणी[संख्या] स्ट्रिंग है | अपरिभाषित, तो आपके पास लिखने पर एक सुदृढ़ता समस्या है:

मेरी राय में, Array<string>[number] हमेशा string|undefined होना चाहिए। यह वास्तविकता है, अगर मैं किसी भी संख्या के साथ एक सरणी में अनुक्रमित करता हूं, तो मुझे या तो सरणी का आइटम प्रकार या अपरिभाषित मिल जाएगा। आप वास्तव में वहां और अधिक विशिष्ट नहीं हो सकते हैं जब तक कि आप टुपल्स के साथ सरणी लंबाई एन्कोडिंग नहीं कर रहे हों। लिखने के लिए आपका उदाहरण चेक टाइप नहीं करेगा, क्योंकि आप किसी सरणी अनुक्रमणिका को string|undefined असाइन नहीं कर सकते हैं।

यह "इंडेक्स रीड टाइप" और "इंडेक्स राइट टाइप" दोनों के लिए टाइप सिंटैक्स जोड़ने के लिए ओवरकॉम्प्लेक्स लगता है। विचार?

यह बिल्कुल वैसा ही प्रतीत होता है जैसा होना चाहिए क्योंकि वे दो अलग-अलग चीजें हैं। किसी भी सरणी में कभी भी अनुक्रमणिका परिभाषित नहीं होगी, इसलिए आपके पास हमेशा अपरिभाषित होने की क्षमता होगी। Array<string>[number] का प्रकार string|undefined । यह निर्दिष्ट करने के लिए कि आप T को Array<T> , एक उपयोगिता प्रकार का उपयोग किया जा सकता है (नामकरण महान नहीं): ArrayItemType<Array<string>> = string । यह Record प्रकारों में मदद नहीं करता है, जिसके लिए RecordValue<Record<string, number>, string> = string जैसी किसी चीज़ की आवश्यकता हो सकती है।

मैं मानता हूं कि यहां कोई अच्छा समाधान नहीं है, लेकिन मुझे पूरा यकीन है कि मैं इंडेक्स पढ़ने पर सुदृढ़ता पसंद करूंगा।

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

उस ने कहा, मैं _do_ इसे स्ट्रिंग-अनुक्रमित वस्तुओं में जोड़ने के बारे में दृढ़ता से महसूस करता हूं, क्योंकि यह बताना बहुत मुश्किल है कि क्या foo.bar का हस्ताक्षर सही है (क्षेत्र bar स्पष्ट रूप से परिभाषित होने के कारण), या संभवतः undefined (क्योंकि यह एक अनुक्रमणिका हस्ताक्षर का हिस्सा है)। यदि यह मामला (जो मुझे लगता है कि बहुत अधिक मूल्य वाला है) हल हो जाता है, तो सरणी मामला संभवतः छोटा हो जाता है और शायद करने लायक भी हो जाता है।

यह "इंडेक्स रीड टाइप" और "इंडेक्स राइट टाइप" दोनों के लिए टाइप सिंटैक्स जोड़ने के लिए ओवरकॉम्प्लेक्स लगता है। विचार?

जावास्क्रिप्ट से गेट्टर और सेटर सिंटैक्स को टाइप परिभाषाओं तक बढ़ाया जा सकता है। उदाहरण के लिए, निम्न सिंटैक्स टाइपस्क्रिप्ट द्वारा पूरी तरह से समझा जाता है:

const foo = {
  _bar: "",
  get bar(): string {
    return this._bar;
  },
  set bar(value: string) {
    this._bar = value;
  }
}

हालांकि, TS वर्तमान में इन्हें एक ही प्रकार में "विलय" करता है, क्योंकि यह फ़ील्ड के "प्राप्त" और "सेट" प्रकारों को अलग-अलग ट्रैक नहीं करता है। यह दृष्टिकोण अधिकांश सामान्य मामलों के लिए काम करता है, लेकिन इसकी अपनी कमियां हैं, जैसे गेटर्स और सेटर्स को एक ही प्रकार को साझा करने की आवश्यकता होती है, और गलत तरीके से एक फ़ील्ड को एक गेटर प्रकार असाइन करना जो केवल एक सेटर को परिभाषित करता है।

यदि TS को सभी क्षेत्रों के लिए अलग-अलग "प्राप्त" और "सेट" को ट्रैक करना था (जिसकी कुछ वास्तविक प्रदर्शन लागतें हो सकती हैं) तो यह इन विचित्रताओं को हल करेगा, और इस मुद्दे में वर्णित सुविधा का वर्णन करने के लिए एक तंत्र भी प्रदान करेगा:

type foo = {
  [key: string]: string
}

अनिवार्य रूप से इसके लिए आशुलिपि बन जाएगा:

type foo = {
  get [key: string](): string | undefined;
  set [key: string](string): string;
}

मुझे जोड़ना चाहिए कि ऐरे का अर्थ बदलना[संख्या] वास्तव में समस्याग्रस्त है क्योंकि इसका अर्थ यह होगा कि यह ध्वज घोषणा फाइलों की व्याख्या को बदल देता है।

यदि जेनरेट की गई घोषणा फाइलें हमेशा पूर्ण गेटर + सेटर सिंटैक्स का उपयोग करती हैं, तो यह _only_ हस्तलिखित लोगों के लिए एक समस्या होगी। वर्तमान नियमों को शेष शॉर्टहैंड सिंटैक्स पर लागू करना _in definition files only_ यहां एक समाधान हो सकता है। यह निश्चित रूप से संगतता मुद्दों को हल करेगा, लेकिन .ts फ़ाइलों बनाम .d.ts फ़ाइलों को पढ़ने की मानसिक लागत को भी जोड़ देगा।

एक तरफ:

अब निश्चित रूप से, यह गेटर्स/सेटर्स के साथ सूक्ष्म चेतावनियों को _all_ संबोधित नहीं करता है:

foo.bar = "hello"

// TS assumes that bar is now a string, which technically isn't guaranteed when
// custom setters and getters are used.
const result: string = foo.bar

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

मुझे वास्तव में ऐसा लगता है कि मुझे बस टिप्पणियों के हर दो पन्नों में पॉप करना है और फिर से # 2521 पर एक लिंक छोड़ना है।

यह "इंडेक्स रीड टाइप" और "इंडेक्स राइट टाइप" दोनों के लिए टाइप सिंटैक्स जोड़ने के लिए ओवरकॉम्प्लेक्स लगता है। विचार?

नहीं! और कम से कम (क्लिक लिंक...) यहां 116 अन्य लोग मुझसे सहमत हैं। मुझे कम से कम पढ़ने और लिखने का विकल्प अलग-अलग तरीके से प्राप्त करने में बहुत खुशी होगी। यह उस सुविधा के लिए अभी तक एक और बढ़िया उपयोग का मामला है।

कम से कम पढ़ने और लिखने का विकल्प अलग-अलग होने से मुझे बहुत खुशी होगी। यह उस सुविधा के लिए सिर्फ _अभी तक एक और_ महान उपयोग का मामला है।

मेरा मानना ​​​​है कि इरादा यह सवाल करना था कि पढ़ने और लिखने के प्रकारों को संदर्भित करने का कोई तरीका होना चाहिए, उदाहरण के लिए लिखने के प्रकार को संदर्भित करने के लिए Array<string>[number]= जैसा कुछ होना चाहिए?

मुझे #2521 और इस मुद्दे दोनों के समाधान से खुशी होगी यदि दो चीजें होती हैं:

• सबसे पहले, #2521 . के अनुसार गेटर्स और सेटर्स को अलग तरह से टाइप करें
• फिर, इस मुद्दे में चर्चा के अनुसार एक ध्वज बनाएं, जैसे कि Array<string>[number] का "लिखने का प्रकार" string जबकि "पढ़ने का प्रकार" string | undefined ।

मैं (गलती से?) मानता हूं कि पूर्व बाद के लिए आधार तैयार करेगा, देखें https://github.com/microsoft/TypeScript/issues/13778#issuecomment -630770947। मुझे "लिखने के प्रकार" को परिभाषित करने के लिए एक स्पष्ट वाक्यविन्यास की कोई विशेष आवश्यकता नहीं है।

@RyanCavanaugh त्वरित मेटा-प्रश्न: क्या यह अधिक स्पष्ट रूप से बहस करने और अपनी ताकत/कमजोरियों/लागतों को ट्रैक करने के उद्देश्य से एक अलग मुद्दे के रूप में उपरोक्त मेरे विशिष्ट सुझाव के लिए अधिक उपयोगी होगा (विशेष रूप से पूर्ण लागत अनौपचारिक होगी)? या यह सिर्फ शोर जारी करने के लिए जोड़ देगा?

@RyanCavanaugh

const t: Array<string>[number] = "hello";

const t: string लिखने के गोल चक्कर के रूप में।

मुझे लगता है कि टुपल्स के लिए भी यही तर्क है?

const t : [string][number] = 'hello' // const t: string

हालांकि टुपल्स सीमाओं के बारे में जानते हैं और अधिक विशिष्ट संख्या प्रकारों के लिए undefined ठीक से लौटाते हैं:

const t0: [string][0] = 'hello' // ok
const t1: [string][1] = 'hello' // Type '"hello"' is not assignable to type 'undefined'.

// therefore this is already true!
const t2: [string][0|1] // string | undefined 

number किसी भी तरह से अलग तरीके से कार्य क्यों करेंगे?

ऐसा लगता है कि ऐसा करने के लिए आपके पास तंत्र मौजूद है: https://github.com/microsoft/TypeScript/issues/38779

यह अतिरिक्त ध्वज जोड़े बिना मेरी जरूरतों को पूरा करेगा।

यदि यह किसी की मदद करता है, तो यहां एक ESLint प्लगइन है जो असुरक्षित ऐरे एक्सेस और ऐरे/ऑब्जेक्ट डिस्ट्रक्टिंग को फ़्लैग करता है। यह टुपल्स और (गैर-रिकॉर्ड) ऑब्जेक्ट्स जैसे सुरक्षित उपयोगों को ध्वजांकित नहीं करता है।

https://github.com/danielnixon/eslint-plugin-total-functions

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

@RyanCavanaugh

हमने यह भी परीक्षण किया है कि यह सुविधा व्यवहार में कैसी दिखती है और मैं आपको बता सकता हूं कि यह सुंदर नहीं है

बस जिज्ञासु, क्या आप हमें बता सकते हैं कि नॉट ब्यूटीफुल पार्ट क्या है? यदि आप इसके बारे में अधिक जानकारी साझा कर सकते हैं तो शायद हम इसे सुलझा सकें।

यह एक विकल्प नहीं होना चाहिए, यह डिफ़ॉल्ट होना चाहिए।

यही है, अगर टाइपस्क्रिप्ट की टाइप सिस्टम को संकलन-समय पर वर्णन करना है कि जावास्क्रिप्ट मान रन-टाइम पर किस प्रकार ले सकते हैं:

• Array को अनुक्रमणित करना निश्चित रूप से जावास्क्रिप्ट में undefined लौटा सकता है (सूचकांक सीमा या विरल सरणी से बाहर), इसलिए सही पढ़ा गया हस्ताक्षर T | undefined ।
• Array में एक इंडेक्स को "कारण" करना undefined होना भी delete कीवर्ड के माध्यम से संभव है।

जैसा कि टाइपस्क्रिप्ट 4 रोकता है

const a = [1, 2]
delete a[1]

a[1] = undefined रोकने के लिए भी एक अच्छा मामला है।
यह सुझाव देता है कि Array<T>[number] वास्तव में पढ़ने और लिखने के लिए अलग होना चाहिए।

यह "जटिल" हो सकता है लेकिन यह जावास्क्रिप्ट में रन-टाइम संभावनाओं को अधिक सटीक रूप से मॉडल करने की अनुमति देगा;
कौन सा टाइपस्क्रिप्ट _के लिए बनाया गया था, है ना?

| undefined को डिफ़ॉल्ट व्यवहार वापस करने के विचार पर चर्चा करने का कोई मतलब नहीं है - वे कभी भी टाइपस्क्रिप्ट का एक संस्करण जारी

हालांकि मैं बाकी पोस्ट से सहमत हूं।

| undefined को डिफ़ॉल्ट व्यवहार वापस करने के विचार पर चर्चा करने का कोई मतलब नहीं है - वे _never_ टाइपस्क्रिप्ट का एक संस्करण जारी करेंगे जो एक कंपाइलर अपडेट के कारण विरासत कोड की लाखों लाइनों को विस्फोट कर देता है। इस तरह का एक बदलाव मेरे द्वारा अब तक की गई किसी भी परियोजना में सबसे ज्यादा तोड़ने वाला बदलाव होगा।

हालांकि मैं बाकी पोस्ट से सहमत हूं।

नहीं अगर यह एक विन्यास विकल्प है।

नहीं अगर यह एक विन्यास विकल्प है।

यह उचित है, लेकिन कम से कम मैं एक लंबी "लीड इन" अवधि की अपेक्षा करता हूं जहां यह डिफ़ॉल्ट रूप से बंद है, लोगों को विरासत कोड को चालू होने से पहले परिवर्तित करने के लिए बहुत समय (6 महीने? एक वर्ष? अधिक?) -चूक जाना। जैसे, v4.0 में ध्वज जोड़ें, इसे v5.0 में ऑन-बाय-डिफॉल्ट पर सेट करें, उस तरह की चीज।

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

| undefined को डिफ़ॉल्ट व्यवहार वापस करने के विचार पर चर्चा करने का कोई मतलब नहीं है - वे _never_ टाइपस्क्रिप्ट का एक संस्करण जारी करेंगे जो एक कंपाइलर अपडेट के कारण विरासत कोड की लाखों लाइनों को विस्फोट कर देता है। इस तरह का एक बदलाव मेरे द्वारा अब तक की गई किसी भी परियोजना में सबसे ज्यादा तोड़ने वाला बदलाव होगा।

हालांकि मैं बाकी पोस्ट से सहमत हूं।

आपकी बात पर @thw0rted मैंने यहां एक समझौता प्रस्तावित किया: https://github.com/microsoft/TypeScript/issues/38779

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

के लिए "strict" स्थिरता के बारे में कुछ Array<T> के रूप में देखा जाना चाहिए "a list of type T that is infinitly long with no gaps" कभी भी इसकी आवश्यकता नहीं पड़ती आप tuples का उपयोग करना चाहिए ..

हां, इसमें कुछ कमियां हैं, लेकिन एक बार फिर मुझे लगता है कि यह इस सुविधा के बीच एक उचित "समझौता" है जिसे कभी भी लागू नहीं किया जा रहा है और ठीक उसी तरह लागू किया गया है जैसा हम यहां पूछ रहे हैं।

अगर आप सहमत हैं तो अपवोट करें

मैं असहमत हूं कि इसके लिए एक बिल्कुल नए विकल्प/कॉन्फ़िगरेशन की आवश्यकता है।

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

इस सूत्र को पढ़ने योग्य बनाए रखने के हित में, मैंने कई स्पर्शरेखा टिप्पणियों को छिपा दिया है जो सार्थक रूप से बातचीत में शामिल नहीं हो रही थीं। सामान्य तौर पर, आप मान सकते हैं कि निम्नलिखित नस में टिप्पणियां पूर्ववर्ती 212 टिप्पणियों में पहले की गई हैं और उन्हें दोहराने की आवश्यकता नहीं है:

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

बहुत वास्तविक व्यावहारिक और तकनीकी चुनौतियां हैं जिन्हें यहां हल करने की आवश्यकता है और यह निराशाजनक है कि हम इस धागे में सार्थक काम नहीं कर सकते क्योंकि यह लोगों से भरा हुआ है जो यह सुझाव देते हैं कि ध्वज के पीछे किसी भी चीज़ का कोई वास्तविक परिणाम नहीं है या कोई त्रुटि जो कर सकती है be ts-ignore 'd एक अपग्रेड बोझ नहीं है।

@RyanCavanaugh

आपके सारांश के लिए धन्यवाद।

अभूतपूर्व परिवर्तनों की वकालत करने के लिए यहां आने से पहले कृपया परियोजना के दीर्घकालिक डिजाइन लक्ष्यों के साथ अधिक जुड़ाव रखें

मैंने अपनी टिप्पणी हटा दी है और यदि आप चाहें तो मैं इस टिप्पणी को भी हटा सकता हूं। लेकिन परियोजना के पहले लक्ष्य को कैसे समझें:

1. सांख्यिकीय रूप से उन निर्माणों की पहचान करें जिनमें त्रुटि होने की संभावना है।

(स्रोत: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)

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

ठीक है अब जब आप इसे इस तरह से रखते हैं तो मुझे विश्वास हो जाता है

बेशक, आप मुख्य अनुरक्षकों में से एक हैं और टीएस के लिए आपको और टीम और योगदानकर्ताओं को धन्यवाद देते हैं। लेकिन यह अब आपके बस की बात नहीं है। अपवोट की तुलना करें: 365 डाउनवोट्स के साथ: 6! केवल ६! यह टाइपसेफ्टी की भारी मांग को दर्शाता है।

लेकिन चलो समाधान के बारे में बात करते हैं। क्या कोई समाधान है जो टीम करेगी या सोच सकती है?

क्या आप इस मामले में ts-ignore साथ क्या गलत है, इस पर थोड़ा और विस्तार कर सकते हैं? मेरा मतलब है कि इसे कोडमॉड जैसे उपकरणों के साथ स्वचालित किया जा सकता है और वर्तमान कोड के व्यवहार को नहीं बदलता है। बेशक यह सुंदर समाधान नहीं है, लेकिन ठीक है, यह बिना झंडे के इस बदलाव को पेश करने का एक संभावित तरीका है।

आप ts के पैच किए गए संस्करण के स्वचालित प्रकाशन के बारे में क्या सोचते हैं, उदाहरण के लिए 4.0.0-breaking ? यह संघर्षों पर कुछ (बहुत?) काम पेश करता है, लेकिन यह सभी को परिवर्तनों का परीक्षण करने और कोड आधार तैयार करने की अनुमति देता है (न केवल इस सुविधा अनुरोध के लिए)। यह कुछ सीमित समयावधि के लिए किया जा सकता है, जैसे 3-6 महीने। हम पहले होंगे, जो इस संस्करण का उपयोग करेंगे।

अब और। अपवोट की तुलना करें: 365 डाउनवोट्स के साथ: 6! केवल ६! यह टाइपसेफ्टी की भारी मांग को दर्शाता है।
- @ बेसोनोव

हा-हा।
ऐसा नहीं है कि मैं @RyanCavanaugh की पूरी पोस्ट से सहमत हूं .. लेकिन … चलो ..
वहाँ क्या लाखों हैं? टीएस उपयोगकर्ता वहाँ से बाहर हैं?!? ३६५ चाहते हैं कि यह सुविधा इस थ्रेड में टिप्पणी और अपवोट करने के लिए पर्याप्त है...

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

@RyanCavanaugh हमें इसके साथ खेलने का मौका देने के लिए बहुत-बहुत धन्यवाद। मैं इसे एक बहुत छोटे (~ 105 ts (x) फाइलों) कोड बेस के खिलाफ चलाता हूं और इसके साथ थोड़ा सा खेला। मुझे कोई महत्वपूर्ण मुद्दा नहीं मिला। एक पंक्ति जिसे से बदल दिया गया था:

const refHtml = useRef(useMemo(() => document.getElementsByTagName('html')[0], []))

प्रति:

const refHtml = useRef(useMemo(() => document.getElementsByTagName('html')[0] ?? null, []))

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

@ lonewarrior556 यह 60 गुना अधिक है और यदि आप upvotes द्वारा क्रमबद्ध करते हैं तो यह पहले पृष्ठ पर है :)

@ बेसोनोव मुझे लगता है कि आपको इसे टाइपस्क्रिप्ट कंपाइलर कोडबेस पर आज़माना चाहिए, यह संभवतः फॉर-लूप के गैर-तुच्छ उपयोग के कारण बड़े पैमाने पर टूट-फूट का कारण बनेगा।

आपके पास पश्चगामी संगतता प्रदान करने के लिए ऑप्ट इन/आउट करने के लिए फ़्लैग भी हो सकते हैं।

आपके द्वारा जोड़ा गया प्रत्येक ध्वज एक और कॉन्फ़िगरेशन मैट्रिक्स है जिसे परीक्षण और समर्थित करने की आवश्यकता है। इसी कारण से टाइपस्क्रिप्ट कम से कम झंडे रखना चाहता है।

@MatthiasKunnen अगर यह कुछ छोटे किनारे के मामले की सुविधा थी तो मैं सहमत हूँ कि इसके लिए एक झंडा नहीं जोड़ने का एक व्यवहार्य कारण है। लेकिन डायरेक्ट ऐरे एक्सेस कोड में काफी बार दिखाई देता है, और टाइप सिस्टम में एक चमकदार छेद और ठीक करने के लिए एक ब्रेकिंग बदलाव भी है, इसलिए मुझे लगता है कि एक झंडा जरूरी होगा।

एक ध्वज इसके लिए गलत दृष्टिकोण है, आंशिक रूप से संयोजन के कारण
संकट। हमें बस इस टाइपस्क्रिप्ट को v5... उस तरह का दृष्टिकोण कहना चाहिए
परीक्षण योग्य संयोजनों की संख्या को 2^N से केवल N में बदल देता है...

शनिवार, 15 अगस्त 2020 को 15:56 बजे, माइकल बर्कमैन नोटिफिकेशन @github.com
लिखा था:

@MatthiasKunnen https://github.com/MatthiasKunnen अगर यह कुछ थे
छोटे किनारे के मामले की सुविधा तो मैं सहमत हूँ कि यह एक व्यवहार्य कारण नहीं है
इसके लिए एक झंडा जोड़ें। लेकिन डायरेक्ट ऐरे एक्सेस कोड में काफी दिखाई देता है
अक्सर, और दोनों प्रकार की प्रणाली में एक चमकदार छेद है और एक
ठीक करने के लिए परिवर्तन को तोड़ना, इसलिए मुझे लगता है कि ध्वज की आवश्यकता होगी।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-674408067 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAADY5AXEY65S5HDGNGIPZDSA2O3FANCNFSM4C6KEKAA
.

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

अगले १० लोगों के बारे में जो यहां टिप्पणी करना चाहते हैं, इसके बजाय पीआर #३९५६० के मसौदे का परीक्षण करें?

यह बहुत कष्टप्रद है यदि आप ESLint के @typescript-eslint/no-unnecessary-condition नियम को सक्षम करना चाहते हैं क्योंकि यह तब सभी उदाहरणों के बारे में शिकायत करता है

if (some_array[i] === undefined) {

यह सोचता है कि यह एक अनावश्यक शर्त है (क्योंकि टाइपस्क्रिप्ट कहता है कि यह है!) लेकिन ऐसा नहीं है। मैं वास्तव में अपने कोडबेस में // eslint-disable-next-line @typescript-eslint/no-unnecessary-condition जोड़ना नहीं चाहता।

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

if (some_array[?i] === undefined) {

(यादृच्छिक वाक्यविन्यास सुझाव; विकल्प स्वागत है)

@Timmmm कृपया आपके द्वारा की गई टिप्पणी के ठीक ऊपर पढ़ें। एक ऐसा निर्माण है जिसे आप आजमा सकते हैं जो इस सुझाव के एक संस्करण को लागू करता है -- यदि यह आपकी eslint समस्या का समाधान करता है तो आप हमें वहां बता सकते हैं।

@ the0rted मैंने वह टिप्पणी पढ़ी। यह मेरे सुझाव के एक संस्करण को लागू नहीं करता है। हो सकता है कि आप इसे फिर से पढ़ना चाहिए।

क्षमा करें, जब मैंने "यह" सुझाव कहा तो मेरा मतलब ओपी में क्षमता था, यानी array_of_T[i] को T | undefined । मैं देखता हूं कि आप एक विशिष्ट इंडेक्स ऑपरेटर को "शायद अपरिभाषित" के रूप में चिह्नित करने के लिए एक वाक्यविन्यास के बारे में पूछ रहे हैं, लेकिन यदि आप रयान के पीआर में कार्यान्वयन का उपयोग करते हैं, तो आपको इसकी आवश्यकता नहीं होगी, क्योंकि सभी इंडेक्स ऑपरेटर "शायद अपरिभाषित" होंगे। . क्या यह आपकी जरूरत को पूरा नहीं करेगा?

हाँ यह होगा - अगर/जब यह उतरता है तो मैं निश्चित रूप से इसका उपयोग करूंगा। लेकिन मुझे इस चर्चा से यह आभास हुआ कि बहुत से लोग इसके लिए प्रतिरोधी थे क्योंकि यह एक अतिरिक्त ध्वज जोड़ता है और ऐसा कोड बनाता है जो ऐसा लगता है कि इसे और अधिक जटिल काम करना चाहिए (लूप उदाहरण के लिए सरल)।

इसलिए मैं एक वैकल्पिक सुझाव देना चाहता था, लेकिन जाहिर तौर पर लोग इससे नफरत करते हैं। :-/

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

मेरे लिए, नए ऑप्ट-इन सिंटैक्स को पेश करने की तुलना में पूरे बोर्ड में टाइप सुरक्षा में सुधार करने वाला ध्वज जोड़ना बहुत कम लागत है।

मैंने ऊपर इसका उल्लेख नहीं किया, लेकिन एकबारगी ओवरराइड के लिए एक सिंटैक्स पहले से मौजूद है: if ((some_array[i] as MyType | undefined) === undefined) । यह एक नए आशुलिपि के रूप में संक्षिप्त नहीं है, लेकिन उम्मीद है कि यह एक ऐसा निर्माण नहीं है जिसका आपको बहुत बार उपयोग करना होगा।

_मूल रूप से @osyrisrblx द्वारा https://github.com/microsoft/TypeScript/issues/40435#issuecomment -690017567_ में पोस्ट किया गया

हालांकि यह एक अधिक सुरक्षित विकल्प की तरह लगता है, दुर्लभ अवसर के लिए एक अलग सिंटैक्स के साथ इस व्यवहार से ऑप्ट-आउट करना अच्छा होगा जहां आप 100% सुनिश्चित हैं कि यह हमेशा परिभाषित होता है।

शायद !: हमेशा परिभाषित किया जा सकता है?

interface X {
    [index: string]!: number; // -> number
}

interface Y {
    [index: string]: number; // -> number | undefined
}

वह सुझाव समस्या का गलत वर्णन करता है। मुद्दा टाइपस्क्रिप्ट के प्रकार की समझ के साथ नहीं है। मुद्दा _accessing_ डेटा से आता है, जो कि इस थ्रेड में पहले से ही नया सिंटैक्स प्रस्तावित किया जा चुका है।

आप इसे टाइपस्क्रिप्ट 4.1 बीटा में आज़मा सकते हैं, जल्द ही आ रहा है ™ (या आज रात की रात अगर आपको अभी इसकी आवश्यकता है! 🙂)

क्षमा करें यदि यह पहले पेश किया गया था, लेकिन क्या {[index: string]?: number} // -> number | undefined समर्थित हो सकता है? यह इंटरफ़ेस वैकल्पिक गुण सिंटैक्स के अनुरूप है - डिफ़ॉल्ट रूप से आवश्यक, संभवतः "?" के साथ अपरिभाषित।

4.1 में कंपाइलर विकल्प अच्छा है, लेकिन अधिक दानेदार नियंत्रण भी अच्छा होगा।

यदि आप इसे अपने रेपो में आज़माना चाहते हैं (मुझे पता लगाने में थोड़ा समय लगा):

1. टाइपप्रति स्थापित करें yarn (add|upgrade) typescript@next
2. झंडा जोड़ें (मेरे लिए tsconfig.json में) "noUncheckedIndexedAccess": true

इस नियम को अपने प्रोजेक्ट पर सक्षम करने की प्रक्रिया में, मुझे यह दिलचस्प त्रुटि मिली:

type MyRecord = { a: number; b: string };

declare const myRecord: MyRecord;

declare const key: 'a' | 'b';
const value = myRecord[key]; // string | number ✅

// ❌ Unexpected error
// Type 'MyRecord[Key] | undefined' is not assignable to type 'MyRecord[Key]'
const fn = <Key extends keyof MyRecord>(key: Key): MyRecord[Key] => myRecord[key];

इस मामले में मुझे myRecord[key] प्रकार MyRecord[Key] | undefined वापस आने की उम्मीद नहीं थी, क्योंकि key keyof MyRecord सीमित है।

अद्यतन : दायर मुद्दा https://github.com/microsoft/TypeScript/issues/40666

हालांकि यह शायद एक बग/निरीक्षण है!

इस नियम को अपने प्रोजेक्ट पर सक्षम करने की प्रक्रिया में, मुझे यह दिलचस्प त्रुटि मिली:

type MyRecord = { a: number; b: string };

declare const myRecord: MyRecord;

declare const key: 'a' | 'b';
const value = myRecord[key]; // string | number ✅

// ❌ Unexpected error
// Type 'MyRecord[Key] | undefined' is not assignable to type 'MyRecord[Key]'
const fn = <Key extends keyof MyRecord>(key: Key): MyRecord[Key] => myRecord[key];

इस मामले में मुझे myRecord[key] प्रकार MyRecord[Key] | undefined वापस आने की उम्मीद नहीं थी, क्योंकि key keyof MyRecord सीमित है।

मैं कहूंगा कि यह एक बग है। मूल रूप से यदि keyof Type केवल स्ट्रिंग/संख्या शाब्दिक प्रकार शामिल हैं (वास्तव में string या number ), तो Type[Key] जहां Key extends keyof Type मुझे लगता है कि undefined शामिल नहीं होना चाहिए।

#13195 से क्रॉस-लिंकिंग, जो "यहां कोई संपत्ति नहीं है" और "यहां एक संपत्ति है लेकिन यह undefined " के बीच अंतर और समानता को भी देखता है।

डिज़ाइन की सीमाओं से संबंधित कुछ समस्याओं को यहाँ ट्रैक करना

• #41612

एफवाईआई: मैंने अपने कोडबेस में दो बग पकड़े इस ध्वज के लिए धन्यवाद, बहुत बड़ा धन्यवाद!
यह थोड़ा कष्टप्रद है कि जाँच arr.length > 0 रक्षा करने के लिए पर्याप्त नहीं है arr[0] , लेकिन वह एक छोटी सी असुविधा अतिरिक्त सुरक्षा की तुलना में, IMO (मैं tsc खुश करने के लिए जांच को फिर से लिखने जा सकता है) है।

@rubenlg मैं arr.length बारे में सहमत हूं। पहले तत्व की जाँच के लिए मैंने अपना कोड फिर से लिखा है जैसे

const firstEl = arr[0];
if (firstEl !== undefined) {
  ...
}

लेकिन कुछ जगहें ऐसी भी हैं जहां हम if (arr.length > 2) या इससे ज्यादा करते हैं, जो थोड़ा अजीब है। हालांकि मुझे नहीं लगता कि चेकिंग .length वैसे भी पूरी तरह से सुरक्षित होगी क्योंकि आप इसे संशोधित कर सकते हैं:

const a: number[] = [];

a.length = 1;

if (a.length > 0) {
    const b: number = a[0];
    console.log(b);
}

undefined प्रिंट करता है।

हालांकि मुझे नहीं लगता कि चेकिंग .length वैसे भी पूरी तरह से सुरक्षित होगी क्योंकि आप इसे संशोधित कर सकते हैं:

const a: number[] = [];

a.length = 1;

if (a.length > 0) {
    const b: number = a[0];
    console.log(b);
}

undefined प्रिंट करता है।

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

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

const a: number[] = [1]
if (a.length > 0) {
    a.pop();
    console.log(a[0])
}