+1, यह टाइपस्क्रिप्ट में कार्यात्मक प्रोग्रामिंग के लिए वास्तव में उपयोगी है! यह वैकल्पिक या बाकी तर्कों के साथ कैसे काम करेगा? अधिक ठोस, क्या compose फ़ंक्शन का उपयोग बाकी तर्कों या वैकल्पिक तर्कों वाले कार्यों पर किया जा सकता है?

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

असल में संघ के प्रकार शायद बेहतर काम करेंगे। कुछ इस तरह

function f(a: string, b? number, ...c: boolean[]): number;
function id<T>(t: T): T;
let g = compose(f, id): (...ts: ([string] | [string, number] | [string, number, boolean[]]) => number

g("foo"); // ok
g("foo", 12); // ok
g("foo", 12, [true, false, true]); // ok

हालाँकि, यह अभी भी बाकी मापदंडों को तोड़ता है।

@ahejlsberg , आपके पास कुछ विचार थे कि

तो: +1: इस पर। जानकारी के लिए यह #3870 से संबंधित है (और पूरा करेगा)। हमने टाइपस्क्रिप्ट में एक कंपोज़ टाइप एपीआई को लागू करने की कोशिश की है, लेकिन इस प्रस्ताव में उल्लिखित कुछ सीमाओं के आसपास काम करना पड़ रहा है। यह निश्चित रूप से उनमें से कुछ समस्याओं का समाधान करेगा!

ऐसा लगता है कि कभी-कभी आप इस तरह के टपल प्रकारों को बनाए रखने के बजाय "विलय" करना चाहते हैं, खासकर कुछ जैसे लिखें। उदाहरण के लिए:

function compose<T, ...U>(base: T, ...mixins: ...U): T&U {
    /* mixin magic */
}

साथ ही, आपके बहुत से उदाहरणों में, आप प्रिमिटिव का उपयोग करते रहे हैं। आप कुछ अधिक जटिल काम को कैसे देखेंगे, खासकर अगर संघर्ष हैं?

दुर्भाग्य से इस प्रस्ताव के रूप में #3870 या प्रकार की संरचना को संबोधित नहीं किया गया है, क्योंकि टपल प्रकार के लिए एकमात्र रचना ऑपरेटर [T,...U] । आप इसे T + ...U रूप में भी लिख सकते हैं (जो कि प्रकारों के साथ क्या होता है इसका अधिक संकेत है), लेकिन #3870 और आपकी टाइप कंपोजिशन लाइब्रेरी को T & ...U । मुझे लगता है कि संभव हो सकता है, लेकिन मैं समझने की जरूरत है @JsonFreeman की और @jbondc 'पहली # 3870 से विचारों। मैं प्रस्ताव का विस्तार करूंगा यदि मैं यह पता लगा सकूं कि इसे कैसे काम करना चाहिए।

नोट: मैंने सिंटैक्स [...T, ...U] साथ जाने का फैसला किया क्योंकि यह समान मूल्य फैलाने वाले सिंटैक्स की तरह दिखता है, लेकिन T + ...U प्रकारों के साथ क्या हो रहा है इसका अधिक संकेत है। यदि हम दोनों के साथ समाप्त होते हैं, तो + और & उपयोग करने वाले ऑपरेटर हो सकते हैं।

बड़ा: +1: इस पर!

+1 बढ़िया! यह ऐसी चीजों को अधिक अभिव्यंजक और हल्के ढंग से व्यक्त करने की अनुमति देगा।

#3870 में मेरी बात यहां एक मुद्दा प्रतीत होती है। विशेष रूप से, मैं विविध प्रकार के मापदंडों के लिए प्रकार के तर्कों के बारे में चिंता करता हूं।

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

यह कितना गंभीर है? मुझे लगता है कि यह इस बात पर निर्भर करता है कि अनुमान वास्तव में कैसे काम करता है। निम्नलिखित का परिणाम क्या है:

function f<...T>(x: ...T, y: ...T): ...T { }
f(['hello', 0, true], [[], 'hello', { }]); // what is the type returned by f?

@jbondc , - एक अच्छे विचार की तरह लगता है। मैं इसे ध्यान में रखूंगा लेकिन इसे यहां नहीं खोजूंगा, क्योंकि मुझे लगता है कि हमें एक बार में नए प्रकार के ऑपरेटरों को पेश करना चाहिए। दोनों & और + नए प्रकार बनाते हैं, लेकिन & एक प्रतिच्छेदन प्रकार बनाता है जबकि + एक नया टपल प्रकार बनाता है (यही कारण है कि मैं सिंटैक्स [T,...U] पसंद करता हूं) T + ...U , क्योंकि [T,U] पहले से ही प्रकारों के लिए ऐसा करता है)।

@JsonFreeman मुझे लगता है कि दोहराए गए पैरामीटर के साथ दो चीजों में से एक करना ठीक है:

1. संघ के प्रकार: f(['hello', 1], [1, false]): [string | number, number | boolean]
2. बार-बार टपल प्रकार के मापदंडों के अनुमान को अस्वीकार करें, खासकर अगर टाइप तर्क अनुमान जटिल साबित होता है। कुछ इस तरह:

f(['hello', 1], [1, false]) // error, type arguments required
f<[string, number]>(['hello', 1], [1, false]) // error, 'number' is not assignable to 'string'
f<[string | number, number | boolean]>(['hello', 1], [1, false]); // ok

मुझे लगता है कि वास्तविक पुस्तकालय (जैसे प्रतिक्रियाशील एक्सटेंशन @Igorbek से जुड़े) में आमतौर पर केवल एक टपल प्रकार का पैरामीटर होगा, भले ही न तो (1) और न ही (2) विशेष रूप से प्रयोग योग्य हों, यह वास्तविक दुनिया कोड को ज्यादा प्रभावित नहीं करना चाहिए।

ऊपर के उदाहरणों में, curry अनुमान लगाना सबसे कठिन है -- आपको f: (...args:[...T,...U]) => V को छोड़ना होगा, अनुमान लगाना होगा ...ts:...T , फिर वापस जाएं और ...U को जो है उसे सेट करें ...T से f के मापदंडों का उपभोग करने के बाद छोड़ दिया।

मैंने इसका प्रोटोटाइप बनाना शुरू कर दिया है (sandersn/TypeScript@1d5725d), लेकिन अभी तक यह नहीं मिला है। कोई विचार अगर वह काम करेगा?

मैं ऐसी किसी भी चीज़ को अस्वीकार करने के पक्ष में हूँ जहाँ शब्दार्थ स्पष्ट नहीं है (जैसे समान फैले हुए प्रकार के पैरामीटर के लिए बार-बार अनुमान)। यह मेरी चिंता को ऊपर भी दूर करता है।

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

उस ने कहा, मुझे लगता है कि यह एक कोशिश के काबिल है। इस फीचर की काफी डिमांड है।

मुझे लगता है कि आपको एक ही संदर्भ में होने वाले कई टपल प्रकारों को छोड़ना होगा (उदाहरण के लिए शीर्ष-स्तर जैसे (...T,string,...U) => V या [...T,...U,...T] जैसे संयोजित)। फिर आप छोड़े गए प्रकारों पर एकाधिक पास बना सकते हैं, पहले से अनुमानित प्रकारों को समाप्त कर सकते हैं और फिर भी अस्पष्ट प्रकारों को फिर से छोड़ सकते हैं। यदि किसी भी बिंदु पर अनुमान के लिए कोई एक प्रकार उपलब्ध नहीं है, तो रोकें और एक त्रुटि वापस करें।

इसलिए। जटिल।

आप इसी तरह की समस्या से प्रेरणा लेने में सक्षम हो सकते हैं। यह वास्तव में कुछ हद तक एक संघ या चौराहे का उल्लेख करने की समस्या के समान है। जब एक संघ प्रकार का उल्लेख किया जाता है जिसमें एक प्रकार पैरामीटर शामिल होता है जो अनुमान संदर्भ का सदस्य होता है, जैसा कि function f<T>(x: T | string[]) , तो आप नहीं जानते कि टी का अनुमान लगाना है या नहीं। संघ प्रकार की इच्छित अभिव्यक्ति हो सकती है string[] । तो टाइपस्क्रिप्ट पहले अन्य सभी घटकों का अनुमान लगाता है, और फिर यदि कोई अनुमान नहीं लगाया जाता है, तो टी का अनुमान लगाया जाता है।

चौराहे के मामले में, यह और भी कठिन है क्योंकि आपको विभिन्न चौराहे घटकों में तर्क के प्रकार को विभाजित करना पड़ सकता है। टाइपस्क्रिप्ट चौराहे के प्रकारों का बिल्कुल भी अनुमान नहीं लगाता है।

क्या होगा यदि आपने केवल अनुक्रम में अंतिम प्रकार होने पर टुपल फैलाने की अनुमति दी है? तो [string, ...T] की अनुमति होगी, लेकिन [...T, string] नहीं होगी?

अगर मैं सही ढंग से समझूं, तो यह वास्तव में टाइपस्क्रिप्ट में मिश्रित कहानी को हल करेगा। क्या मैं इस समझ में सही हूँ?

शायद। क्या आप एक उदाहरण दे सकते हैं? मैं मिक्सिन पैटर्न के साथ धाराप्रवाह नहीं हूं।

एक भिन्न प्रकार के चर का सिंटैक्स है ...T जहां T एक पहचानकर्ता है जो परंपरा के अनुसार एक एकल अपर-केस अक्षर है, या T उसके बाद एक PascalCase पहचानकर्ता है।

क्या हम एक प्रकार के पैरामीटर पहचानकर्ता के मामले को डेवलपर पर छोड़ सकते हैं?

@ एलेक्सी-बायकोव +1। मुझे कोई कारण नहीं दिखता कि ऐसा क्यों नहीं होना चाहिए।

हास्केल पृष्ठभूमि वाले डेवलपर्स इसकी सराहना करेंगे।

क्षमा करें, उस वाक्य को अस्पष्ट रूप से पार्स किया जा सकता है। मेरा मतलब था 'या' कसकर पार्स करने के लिए: "सम्मेलन द्वारा (एक अपर-केस अक्षर || टी एक पास्कलकेस पहचानकर्ता के बाद)"। मैं पहचानकर्ताओं के मामले में बाधा डालने का प्रस्ताव नहीं कर रहा हूं, बस सम्मेलन की ओर इशारा कर रहा हूं।

इसके लायक क्या है, हालांकि, _I_ में हास्केल पृष्ठभूमि है और मुझे उस भाषा के सम्मेलनों को तोड़ना पसंद नहीं है जिसमें मैं लिख रहा हूं।

पटरी से उतरने के लिए खेद है। मेरा आखिरी जिज्ञासु प्रश्न (यदि आप मुझसे पूछने में कोई आपत्ति नहीं करते हैं) टाइपस्क्रिप्ट का "सम्मेलन" क्या है जो टूट सकता है और कौन चिंतित है?

@sandersn

इसे T & ...U मानते हुए चेक टाइप करना चाहिए, जिसका अर्थ है T & U & V & ... (जो सहज व्यवहार है)।

function assign<T, U, ...V>(obj: T, src: U, ...srcs: ...V): T & U & ...V {
  if (arguments.length < 2) return <T & U & ...V> obj

  for (const key of Object.keys(src)) {
    (<any> obj)[key] = (<any> src)[key]
  }

  if (arguments.length === 2) return <U> obj
  return mixin<T, ...V>(obj, ...srcs)
}

या परिभाषा फ़ाइल में:

interface Object {
    assign<T, U, ...V>(host: T, arg: U, ...args: ...V): T & U & ...V
}

@ एलेक्सी-बायकोव जिस सम्मेलन के बारे में मैं बात कर रहा हूं वह प्रकार पैरामीटर पहचानकर्ताओं का मामला है। कौन चिंतित है? जिन लोगों को नया टाइपस्क्रिप्ट कोड पढ़ना है, उन्होंने पहले कभी नहीं देखा है -- सम्मेलन नए पाठकों को नए कोड को तेज़ी से समझने में मदद करते हैं।

@sandersn क्या @ एलेक्सी-बायकोव को यह आभास हुआ कि निम्नलिखित _syntactically_ अमान्य होंगे:

function assign<a, b, ...cs>(x: a, y: b, ...zs: ...cs): a & b & ...cs;

@isiahmeadows & और | प्रकार के संचालन इस प्रस्ताव में शामिल नहीं हैं, हालांकि मुझे उन्हें प्रश्न/भविष्य के काम को खोलने के लिए जोड़ना चाहिए यदि मेरे पास नहीं है। अभी एकमात्र प्रस्तावित ऑपरेटर संयोजन है: [THead, ...TTail] ।

एक अंतर यह है कि संयोजन अभी भी एक टपल प्रकार उत्पन्न करता है जबकि & और | क्रमशः चौराहे और संघ प्रकार उत्पन्न करते हैं।

@sandersn टाइपस्क्रिप्ट में मेरा assign उदाहरण इसके साथ बदलने के लिए छोटा होगा।

यद्यपि:

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

@isiahmeadows एक चौराहा सामान्य रूप से शब्दकोशों का एक संयोजन नहीं है। यह केवल वस्तु प्रकारों के प्रतिच्छेदन के लिए सही है, लेकिन उदाहरण के लिए संघों के प्रतिच्छेदन के लिए नहीं। यूनियनें भी वैसी नहीं हैं जैसे केवल गुणों को लेना वस्तुओं में समान है। दोनों में रहने वाले मूल्यों के समूह द्वारा बेहतर रूप से चित्रित किया गया है।

@sandersn मैं भिन्न प्रकार के साथ तर्क तर्क अनुमान के बारे में थोड़ा उलझन में हूं। यहाँ क्या अनुमान लगाया जाना चाहिए?

function foo<...T>(...rest: ...T): ...T { }
foo('str', 0, [0]);

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

मुझे पता है कि यह एक प्रायोगिक / प्रारंभिक प्रस्ताव है, लेकिन हम बाकी मापदंडों के लिए ...T सिंटैक्स पर चर्चा कर सकते हैं। मेरे दृष्टिकोण से, यह वास्तव में काम नहीं करता है।
तो प्रस्तावित वाक्यविन्यास है:

declare function f<...T>(...a: ...T);

आइए बाकी मापदंडों के मौजूदा सिंटैक्स के साथ तुलना करें:

declare function f(...a: number[]);

इसलिए बाकी तर्कों को पकड़ने वाले a पैरामीटर का प्रकार number[] , इसलिए हम स्पष्ट रूप से समझ सकते हैं कि यह एक सरणी है। सादृश्य से, मैं अनुमान लगा सकता हूं कि प्रस्ताव से ...T एक सरणी का भी प्रतिनिधित्व करता है। लेकिन यह बहुत स्पष्ट नहीं है।
अगला, मान लें कि हम अधिक प्रतिबंधात्मक बाकी मापदंडों को परिभाषित कर सकते हैं:

declare function f(...a: [number, string]);
// same as
declare function f(c: number, d: string); // or very close to

तो अब, हम अभी भी देखते हैं कि a का प्रकार एक टपल है (जो एक सरणी है)।

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

var a: [number, string] = [1, "1"];
var b = [true, ...a]; // this must be [boolean, number, string], but it doesn't work :)

तो ...a चर के मामले में, सिर्फ 1, "1" ।

बाकी मापदंडों को ...T धारणा द्वारा परिभाषित करने के लिए मेरा सिंटैक्स:

declare function f<...T>(...a: [...T]);
declare function g<H, ...T>(head: H, ...tail: [...T]): [H, ...T];

मेरे लिए यह बहुत अधिक समझ में आता है।

@Igorbek मैं इस धारणा पर चल रहा हूं कि declare function f<...T>(...a: ...T); पहले से ही इस तरह काम कर रहा है। लेकिन मुझे नहीं लगता कि declare function f(...a: [number, string]); अधिक उपयोग हो रहा है।

अधिक स्पष्ट होना।

बाकी मापदंडों के लिए मूल रूप से प्रस्तावित सिंटैक्स:

function func<...T>(...a: ...T)

अगर मैं यह कर सकता हूँ

function g<...T>(...a: ...T): [number, ...T] { ... }

तो मैं ऐसा करने में सक्षम हो जाऊंगा:

function f<...T>(...a: ...T): [...T] { return a; }

तो a का प्रकार [...T] (हम इसे वापस करते हैं), लेकिन हमने इसे हस्ताक्षर में ...T रूप में परिभाषित किया है।
हम कह सकते हैं कि ...T और [...T] समान हैं, लेकिन यह चर के मामले में काम नहीं करता है।
चर के लिए:

var a = [1, 2];
[a] === [[1,2]];
[...a] === [1, 2];
f(...a) === f(1, 2)
...a === 1, 2 // virtually

यदि हम मानक बाकी मापदंडों के लिए समान लागू करते हैं

function f(...a: number[]): number[] { return a; }

a का प्रकार number[] (रिटर्न प्रकार द्वारा) है, जैसा कि हस्ताक्षर में परिभाषित किया गया था।

@isiahmeadows हाँ, function f(...a: [number, string]) काम नहीं करता है। मैंने अभी इस बारे में विचार विकसित किए हैं कि हम बाकी मापदंडों का इलाज कैसे कर सकते हैं।

तो, आगे जा रहे हैं। प्रकार के मापदंडों को स्पष्ट रूप से परिभाषित करने के लिए, निम्नलिखित सिंटैक्स प्रस्तावित किया गया था:

function f<...T, ...U>()
f<[number, string], [boolean, number]>();

करने के लिए उत्तेजित करता है:

f<...[number, string], ...[boolean, number]>();

तो यह भी काम कर सकता है:

function g<T1, T2, T3>()

g<A, B, C>();
// same as
g<...[A, B, C]>();
g<...[A], ...[B, C]>(); 
g<...[A], B, C, ...[]>();

@JsonFreeman इस तरह मेरा प्रोटोटाइप काम करता है, हां। लेकिन यह समझने के लिए कि यह क्यों काम करता है, मैं टाइप अनुमान एल्गोरिदम से पर्याप्त परिचित नहीं हूं। दूसरे शब्दों में, प्रश्न यह नहीं है कि क्या बाएँ-से-दाएँ अनुमान एक _तुच्छ_ धारणा है बल्कि एक सही है। पहचान के मामले में उत्तर हां है लेकिन मुझे नहीं पता कि क्या आप ऐसे मामले बना सकते हैं जहां उत्तर नहीं है।

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

और भी बेहतर:

function<...T>(...a: T): T;
// same as
function<...T>(...a: [...T]): T;

मैं बाकी प्रकार के पैरा को इंगित करने के लिए टाइप आइडेंटिफ़ायर के लिए [] उपसर्ग करने का सुझाव देता हूं।

function fn<R, []T>(...a:[]T): R;

यह ...T से छोटा 1 वर्ण है और (मेरी राय में) कम दृश्य शोर करता है।

@ एलेक्सी-बायकोव मैं वास्तव में उस पर विपरीत राय का हूं। यह मौजूदा बाकी पैरामीटर सिंटैक्स के साथ फिट नहीं है, इसलिए मेरा मानना ​​​​है कि यह एक नज़र से भी कम स्पष्ट है।

[...T] / T बाकी सरणी पैरामीटर प्रकार के रूप में मेरे लिए बहुत बेहतर लगता है। एक बार फिर, सरणी और उनके स्प्रेड ऑपरेटर के साथ तुलना करें:

| सरणियाँ | प्रकार (प्रस्ताव से) | प्रकार (मेरा अद्यतन) |
| --- | --- | --- |
| var x = [1,2] | नहीं | T = [T1, T2] |
| [0, ...x] === [0,1,2] | [T0, ...T] === [T0, T1, T2] | [T0, ...T] === [T0, T1, T2] |
| f(x) === f([1, 2]) | नहीं | f<T>() === f<[T1, T2]>() |
| f(...x) === f(1, 2) | f<...T>() === f<[T, T2]> ? | f<...T>() === f<T1, T2> |
| f(0, ...x) === f(1, 2) | f<T0, ...T>() === f<T0, [T, T2]> ? | f<T0, ...T>() === f<T0, T1, T2> |

प्रस्ताव से

function g<...T>(...x: ...T) {
 // being called as g(1, "a");
  var a: ...T; // [number, string] ?
  var b: [number, ...T]; // [number, number, string]
  var c: [...T]; // [number, string] - same as a ? so [...T] is same as ...T - weird
}

मेरे अपडेट से

function g<...T>(...x: T) {
 // being called as g(1, "a");
  var a: T; // [number, string]
  var b: [number, ...T]; // [number, number, string]
  var c: [...T]; // [number, string]
}

अद्यतन अब IMO अच्छा लग रहा है। प्रकार का प्रतिनिधित्व करने के लिए सूचियां बहुत अच्छी लगती हैं, लेकिन यहां तक ​​​​कि टाइप की गई लिस्प्स भी इतनी दूर नहीं जाती हैं (समलैंगिक प्रकार, कोई भी?: मुस्कान :)।

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

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

function foo<T>(a: T, b: T): T {}
foo(["hi", 0], ["", ""]);

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

यदि आप ...T द्वारा दर्शाए गए टपल में तत्वों की सूची के रूप में उम्मीदवार सूची पर भरोसा करते हैं तो यहां बहुलताओं के साथ एक समस्या है:

function foo<...T>(...rest: ...T): ...T
foo(0, 1);

मुझे लगता है कि आप अपने प्रस्ताव के इरादे को देखते हुए टी के लिए [number, number] का अनुमान लगाना चाहेंगे जैसा कि मैं इसे समझता हूं। लेकिन चेक इन लाइन https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L6256 के कारण , number उम्मीदवार को केवल एक बार जोड़ा जाएगा, और T का अनुमान [number] रूप में लगाया जाएगा। यह वह बहुलता मुद्दा है जिसके बारे में मैं बात कर रहा था।

आदेश के लिए, यह बाएं से दाएं है। लेकिन कई पास हैं, और तर्कों को पुन: संसाधित किया जाएगा यदि उनमें फ़ंक्शन एक्सप्रेशन शामिल हैं जो प्रासंगिक रूप से टाइप किए जाएंगे। यदि प्रासंगिक रूप से टाइप किए गए फ़ंक्शन एक्सप्रेशन वाले n तर्क हैं, तो तर्कों पर n + 1 पास हैं। एक उदाहरण Array.prototype.reduce है, जहां प्रारंभिक वैल्यू पैरामीटर प्रभावी ढंग से टाइप किया जाता है और कॉलबैक से पहले अनुमान लगाया जाता है, इस तथ्य के बावजूद कि यह दाईं ओर है। तो प्रस्ताव के लिए निम्नलिखित की तरह कुछ एक मुद्दा हो सकता है:

function foo<...T>(...rest: ...T): ...T
foo(x => x, 0);

सहज रूप से, T [(x: any) => any, number] होना चाहिए, लेकिन यदि आप उम्मीदवार को जोड़े जाने के क्रम पर भरोसा करते हैं, तो यह [number, (x: any) => any] । ऐसा इसलिए है क्योंकि टाइप तर्क अनुमान आम तौर पर बाएं से दाएं होता है, लेकिन प्रासंगिक टाइपिंग के अधीन कार्य अंत तक स्थगित कर दिए जाते हैं।

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

@JsonFreeman आपको क्यों लगता है कि यह एक मुद्दा होगा?
इसे वस्तुतः प्रत्येक शेष तथ्यात्मक तर्क के लिए अतिरिक्त सामान्य प्रकारों को पेश करके और निश्चित पैरामीटर लंबाई के साथ फ़ंक्शन के विरुद्ध अनुमान लगाकर कार्यान्वित किया जा सकता है।
उदाहरण के लिए,

function foo<...T>(...rest: T) { ... }
foo(x => x, 0);
// to infer, the following function is used
function foo2<T0, T1>(rest0: T0, rest1: T1) { ... }
foo2(x => x, 0);
// inferred as
foo2<(x: any) => any, number>
// T0 = (x: any) => any
// T1 = number
// T = [T0, T1] = [(x: any) => any, number]

BTW, क्या हम x => x प्रकार का अनुमान लगा सकते हैं { <T>(x: T): T; } ?

@Igorbek मुझे लगता है कि निर्माण प्रकार के मापदंडों के बारे में आपका सुझाव (कम से कम अंतर्ज्ञान के रूप में, इसे कैसे लागू किया जाता है) इसे करने का सही तरीका है। आप T लिए प्रकारों के अनुक्रम का अनुमान लगा सकते हैं, जहां अनुक्रम में प्रत्येक तत्व में एक अनुक्रमणिका और उम्मीदवारों की एक सूची होती है (यह आपके द्वारा उल्लिखित को लागू करने का एक वैकल्पिक तरीका है)।

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

{ <T>(x: T): T; } बारे में आपकी बात के लिए, यह x => foo(x) जैसी चीजों को टाइप करने के लिए अच्छी तरह से सामान्यीकृत नहीं है जहां foo कुछ फ़ंक्शन है। x के लिए ओवरलोड रिज़ॉल्यूशन करने के लिए आपको foo के प्रकार को जानना होगा।

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

1. औपचारिक आराम प्रकार के तर्क

अगर हम इस फॉर्म को चुनते हैं:

type F<...Args> = (...args:...Args) => ...Args

तो हमें इसे इस तरह इस्तेमाल करना चाहिए

var a:  F // a: () => []
var b:  F<number> // b: (arg: number) => [number]
var c:  F<number, string> // c: (arg1: number, arg2: string) => [number, string]
...

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

2. टपल टाइप किए गए बाकी तर्क

(...args:[string, number]) => boolean    IS EQUIVALENT TO   (s: string, n: number) => boolean

इस मामले में हमारे पास औपचारिक प्रकार के पैरामीटर अनुभाग में हमेशा निश्चित संख्या में स्लॉट होते हैं।

function f<T>(...args: T): T {
    return args;
}

हम अनुमान लगाते हैं कि यदि कोई शर्त पूरी होती है तो T एक टपल प्रकार होना चाहिए:

1. T का उपयोग बाकी मापदंडों के लिए किया जाता है जैसे (...args: T) => T
2. T का उपयोग [...T] या [संख्या, ...T, स्ट्रिंग] जैसी प्रसार संरचना में किया जाता है।

इस प्रकार, हमें औपचारिक प्रकार पैरामीटर अनुभाग में एक दीर्घवृत्त का उपयोग करने की आवश्यकता नहीं है (हम इसे बिना किसी प्रकार के चेकर के भी _syntactically_ अनुमान लगा सकते हैं)

इस मामले में, हम यह भी लिख सकते हैं

function f<T>(...args: [...T]): [...T] {
    return args;
}

लेकिन यह बेमानी है।

व्यक्तिगत रूप से, मैं बाद में टाइपस्क्रिप्ट में कार्यान्वित देखना चाहता हूं। @JsonFreeman , @sandersn?

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

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

सामान्य हस्ताक्षरों के लिए, प्रकार तर्क अनुमान के कारण यह अधिक जटिल है। क्या होगा यदि आपके पास निम्नलिखित थे:

function callback(s: string, n: number): void { }
declare function foo<...T>(cb: (...cbArgs: T) => void, ...args: T): [...T];

foo(callback, "hello", 0, 1);

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

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

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

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

@JsonFreeman आपके मामले में foo [string, number, number] लौटाएगा जैसा कि ...args से अनुमान लगाया जाएगा, अनुमानित cb प्रकार (string, number, number) => void और पारित कॉलबैक केवल अंतिम तर्क को अनदेखा करेगा जो TS और JS दोनों में बहुत आम है।

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

ठीक यही वे हैं, जेएस टुपल्स के बारे में नहीं जानता, केवल टीएस। TS के लिए एक टपल प्रकार का एक क्रम है।

मुझे टुपल-आधारित दृष्टिकोण भी पसंद है। खासकर अगर हमारे पास संगत कार्य हस्ताक्षर हो सकते हैं जैसे:

// all are equivalent
(a: A, b: B, c: C) => R;
(a: A, b: B, ...rest: [C]) => R;
(a: A, ...rest: [B, C]) => R;
(...args: [A, B, C]) => R;

// this is more complicated 
(a: A, ...rest: T[]) => R;
(...args: [A, ...T]) => R; // no in current syntax

उत्तरार्द्ध हम वर्तमान सिंटैक्स के साथ व्यक्त नहीं कर सकते हैं, लेकिन अगर हम #6229 को अपनाया होता।
तो मेरे लिए ऐसा लगता है कि अधिक व्यक्त करने के लिए टुपल्स का उपयोग करना और टुपल्स को एकीकृत करना एक उचित तरीका है। अधिक अभिव्यंजक टुपल्स के बिना, [...T, ...T] जैसा कुछ होना कठिन होगा क्योंकि T एक टुपल के रूप में एक खुली लंबाई है।

@JsonFreeman आपके उदाहरण के लिए, @Pajn ने बिल्कुल मेरी समझ के रूप में दिखाया - इन प्रकारों का

@JsonFreeman मैं उस वाक्यविन्यास का बेहतर उपयोग

declare function foo<T>(cb: (...cbArgs: T) => void, ...args: T): T;
declare function foo<T>(cb: (...cbArgs: T) => void, ...args: T): [...T]; // same

हम्म, शायद यह कुछ अस्पष्टता पेश कर सकता है:

declare function foo<T>(...args: T): T;
foo(1); // T is [number] or number[]?

// however, here it'd be more explicit
declare function foo<T>(...args: T[]): T[];
foo(1); // T is number[]

// and here
declare function foo<T>(...args: [...T]): T;
foo(1); // T is [number]

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

@Igorbek आप अपने पहले उदाहरण में अस्पष्टता के बारे में सही हैं। आपका तीसरा उदाहरण भी समस्याग्रस्त है। number, string जैसे अनुक्रम को देखते हुए, हस्ताक्षर के 2 संभावित तत्कालताएं हैं। अर्थात् (arg1: number, arg2: string) => [number, string] और साथ ही (arg1: [number, string]) => [number, string] (उदाहरण के लिए निहित टपल व्याख्या को अपनाना)।

निहित टपल व्याख्या के बारे में दूसरी अजीब बात यह है: मान लें कि आपके पास एक बाकी प्रकार का पैरामीटर T है जिसे number, string तत्काल किया जा रहा है। अब कहें कि आप उन्हें टाइप तर्क के रूप में पास करते हैं, Foo<T> । क्या इसकी व्याख्या Foo<[number, string]> रूप में की जानी चाहिए जबकि Foo<...T> Foo<number, string> ? इसके लिए एक तर्क है, क्योंकि यह स्प्रेड ऑपरेटर को टाइप सिस्टम तक विस्तारित करेगा। लेकिन मैं अभी भी टपल संस्करण को Foo<[...T]> रूप में प्रस्तुत करना चाहता हूं

मुझे पागल कहो, लेकिन मुझे उपयोग करने के विचार के साथ कुछ मूलभूत खामियां महसूस होती हैं
टुपल्स यदि आप एक टपल प्रकार को बहुत अधिक में फैलाने का प्रयास करते हैं तो क्या होता है
पैरामीटर? इस कदर?

declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

साथ ही, क्या होता है यदि टाइप पैरामीटर गलत प्रकार के होते हैं या इनका उपयोग किया जाता है
असामान्य, संभावित रूप से गलत स्थान?

// 1. unusual place
declare foo<T>(x: T, ...ys: [...T]): void

// 2. bad type
declare foo<T>(...xs: [...T]): void
foo<number>(2)

पहला उदाहरण फ़ंक्शन#लागू के लिए सीधे प्रासंगिक है (और हो सकता है a
त्रुटि), और दूसरी एक गैर-स्पष्ट गलती है जो संकलित करने में विफल हो जाएगी,
और Intellisense के साथ पता लगाने के लिए गैर-तुच्छ।

सूर्य पर, २८ फरवरी २०१६, ०३:०४ जेसन फ्रीमैन नोटिफिकेशन @github.com ने लिखा:

निहित टपल व्याख्या के बारे में दूसरी अजीब बात यह है: कहते हैं
आपके पास एक बाकी प्रकार का पैरामीटर टी है जिसे संख्या, स्ट्रिंग के लिए तत्काल किया जा रहा है।
अब कहें कि आप उन्हें टाइप तर्क के रूप में पास करते हैं, फू. क्या यह होना है
फू<[संख्या, स्ट्रिंग]> के रूप में व्याख्या की गई जबकि फू<... टी> फू है स्ट्रिंग>?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -189817561
.

@JsonFreeman

आपका तीसरा उदाहरण भी समस्याग्रस्त है। number, string जैसे अनुक्रम को देखते हुए, हस्ताक्षर के 2 संभावित तत्कालताएं हैं। अर्थात् (arg1: number, arg2: string) => [number, string] और साथ ही (arg1: [number, string]) => [number, string] (उदाहरण के लिए निहित टपल व्याख्या को अपनाना)।

मेरे तीसरे उदाहरण से यह स्पष्ट है कि यह केवल (...args: [number, string]) => [number, string] रूप में व्याख्या कर सकता है:

declare function foo<T>(...args: [...T]): T;
foo(1, "a"); // T is [number, string]
const result: [number, string] = foo<[number, string]>(1, "a");

// however, it is assignable to/from the following signatures:
const f1: (arg1: number, arg2: string) => [number, string] = foo<[number, string]>;
const f2: (arg1: number, ...rest: [string]) => [number, string] = foo<[number, string]>;

निहित टपल व्याख्या के बारे में दूसरी अजीब बात यह है: मान लें कि आपके पास एक बाकी प्रकार का पैरामीटर है T को तत्काल किया जा रहा है number, string ।

T को number, string तत्काल नहीं किया जा सकता क्योंकि यह एक वास्तविक टपल है। यह [number, string] होना चाहिए।

अब कहें कि आप उन्हें टाइप तर्क के रूप में पास करते हैं, Foo<T> । क्या इसकी व्याख्या Foo<[number, string]> रूप में की जानी चाहिए जबकि Foo<...T> Foo<number, string> ?

सत्य। हालांकि, इस विशेष उपयोग के मामलों के लिए <...T> बेमानी लगता है (बाकी तर्कों के लिए स्थिति प्रकारों को पकड़ें)। फिर भी, मान लीजिए कि हमारे पास है।

इसके लिए एक तर्क है, क्योंकि यह स्प्रेड ऑपरेटर को टाइप सिस्टम तक विस्तारित करेगा। लेकिन मैं अभी भी टपल संस्करण को Foo<[...T]> रूप में प्रस्तुत करना चाहता हूं

ऐसे दो मामले हैं जब हम उस सिंटैक्स का उपयोग कर सकते हैं:

// in a signature declaration
declare function foo<[...T]>(...args: [...T]): [...T];
// and when type instantiated, so in the usage
type T = [number, string]
foo<T>();
foo<[...T]>();
// the latter can virtually be replaced as
type _T = [...T]; // which is a type operation that should produce [number, string]
foo<_T>();
// and more
type Extended = [boolean, ...T]; // [boolean, number, string]

तो उपयोग के लिए यह | , & या [] जैसे टाइप ऑपरेटर से ज्यादा कुछ नहीं है। लेकिन घोषणा में कि सिंटैक्स की व्याख्या T extends any[] रूप में की जा सकती है या सभी टुपल्स के लिए जो भी आधार प्रकार है, यह इंगित करने के लिए कि एक टुपल प्रकार होना चाहिए।

@isiahmeadows

यदि आप एक टपल प्रकार को बहुत अधिक में फैलाने का प्रयास करते हैं तो क्या होता है
पैरामीटर? इस कदर?

declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2); // ok, foo<[number]> is of type (...args: [number]) => void
// [1, 2] is being passed in place of args
// is [1, 2] which is [number, number] assignable to [number]? yes, with current rules
// no error

साथ ही, क्या होता है यदि टाइप पैरामीटर गलत प्रकार के होते हैं या इनका उपयोग किया जाता है
असामान्य, संभावित रूप से गलत स्थान?

// 1. unusual place
declare foo<T>(x: T, ...ys: [...T]): void
// 1. [...T] can be interpret as a type constraint "must be a tuple type"
// 2. if we call with type specified
foo<number>(1); // number doesn't meet constraint
foo<[number]>(1, 2); // argument of type 'number' is not assignable to parameter 'x' of type '[number]'
foo<[number]>([1], 2); // ok
// 3. if we call without type, it must be inferred
foo(1); // according to current rules, T would be inferred as '{}[]' - base type of all tuples
        // so, argument of type 'number' is not assignable to parameter 'x' of type '{}[]'
foo([1, 2], 2); // T is inferred as '[number, number]
                // rest arguments of type '[number]' are not assignable to rest parameters 'ys' of type '[number, string]'
foo([1], 2, 3); // T is '[number]',
                // x is of type '[number]',
                // ys is of type '[number]',
                // rest arguments are of type '[number, number]' which is assignable to '[number]',
                // no error

// 2. bad type
declare foo<T>(...xs: [...T]): void
foo<number>(2); // type 'number' doesn't meet constraint

मुझे अभी भी इन चीजों को टुपल्स के रूप में प्रस्तुत करने का लाभ नहीं दिख रहा है। इसके अलावा, मुझे लगता है कि उन्हें <...T> घोषित किया जाना चाहिए न कि <T> । जैसा कि मैंने पहले कहा था, मैं टाइप सिस्टम में मनमानी लंबाई प्रकार अनुक्रमों के लिए उपयोग करने के लिए उपयुक्त डिवाइस के रूप में टुपल प्रकार नहीं देखता हूं। मुझे अभी भी यकीन नहीं हो रहा है कि लोगों को जो अभिव्यक्ति चाहिए, उसके लिए यह आवश्यक है।

मैं सहमत हूं कि यह अधिक अभिव्यंजक हो सकता है, लेकिन टाइप पैरामीटर स्थिति में 'स्प्रेड' ऑपरेटर होने से हम केवल एक बार बाकी तर्कों को पकड़ने के लिए सीमित हो जाएंगे, जैसे कि हमारे पास दो बार बाकी पैरामीटर नहीं हो सकते हैं। तो दिया गया <...T> और <A, B, C> , T उन्हें [A, B, C] रूप में पकड़ लेगा। और हम <...T, ...U> को व्यक्त नहीं कर पाएंगे क्योंकि यह अस्पष्ट होगा - [A, B, C], [] या [A, B], [C] या ... आदि।

मान लीजिए कि मैं निम्नलिखित व्यवहार के साथ एक समारोह व्यक्त करना चाहता था:

declare function foo(a: A, b: B): R;
declare function boo(c: C, d: D, e: E): U;

let combined: (a: A, b: B, c: C, d: D, e: E) => [R, U] = combine(foo, boo);

// so the signature could be:

declare function combine<R, U, ???>(
  f1: (...args: [...T1]) => R,
  f2: (...args: [...T2]) => U):
    (...args: [...T1, ...T2]) => [R, U];

// if ??? is '...T1, ...T2'
combine<R, U, A, B, C, D, E> // what will be T1 and T2 ?
combine<R, U, ...[A, B, C], ...[D, E]> // ok ? so we will preserve spread to specific positions. so then
combine<...[R, U], A, ...[B, C, D], E> // will be restricted.
// however, ES6 allows to do it with function arguments
f(1, 2, 3);
f(...[1, 2], 3);
f(...[1], ...[2, 3]);

// if ??? is 'T1 extends TupleBase, T2 extends TupleBase'
// or just '[...T1], [...T2]' as a shortcut for such constraints
combine<R, U, [A, B, C], [D, E]> // pretty explicit, and doesn't occupy spread operator for type arguments

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

जावास्क्रिप्ट में, यह अधिक की तरह है function foo([...rest]) { } के बजाय function foo(...rest) { } ।

यह अब मुझे और अधिक समझ में आता है, समझाने के लिए धन्यवाद। मुझे लगता है कि यह एक उचित दृष्टिकोण है।

@JsonFreeman बिल्कुल सही!

@JsonFreeman प्रश्न: [1, 2] को [number] संतुष्ट क्यों करना चाहिए? यह मुझे बहुत अजीब लगता है। वास्तव में काम करना बहुत आश्चर्यजनक होगा। यह बिल्कुल भी सुरक्षित नहीं है।

ऐसा नहीं है कि मेरे पास विविध प्रकारों के लिए उपयोग किए जाने वाले टुपल्स के खिलाफ कुछ भी है, हालांकि (मैं तटस्थ हूं, ईमानदार भी हूं)।

@isiahmeadows किस तरह से [1, 2] [number] लिए प्रतिस्थापन योग्य नहीं है? यह निश्चित रूप से एक उपप्रकार है। यह वैसा ही है जैसे { x: 1, y: 2 } एक वैध { x: number }

ठीक। मैं आंशिक रूप से स्वीकार करूंगा, लेकिन Function.prototype.apply को ध्यान में रखता हूं, जो तर्कों का एक समूह स्वीकार करता है।

interface Function<T, U, V> {
    (this: T...args: [...U]): V;
    apply(object: T, args: U): V;
}

यदि कॉलर बहुत अधिक तर्कों पर एक TypeError फेंकता है, तो बहुत अधिक पास करने से रनटाइम त्रुटि होगी, न कि संकलन त्रुटि जैसे कि इसे करना चाहिए।

क्या किसी JS फ़ंक्शन के लिए बहुत अधिक तर्क पारित करने पर TypeError को फेंकना बहुत दुर्लभ नहीं है? कुछ उदाहरण क्या हैं?

@isiahmeadows एक अमूर्त उदाहरण के रूप में, मैं समझ गया कि जिस त्रुटि के बारे में आप चिंतित हैं वह है:

function f(x: number): void {
  // throw if too many arguments
}
f.apply(undefined, [1,2,3]); // runtime error, no compile-time error
f(1,2,3) // compile-time error and runtime error.

क्या वो सही है?

@sandersn , मुझे लगता है कि बहुत से तर्कों पर TypeError कुछ ऐसा है जो जेएस की भावना का उल्लंघन करता है, क्योंकि हम आम तौर पर इस फ़ंक्शन में पारित होने वाले वास्तविक लोगों की तुलना में कम औपचारिक तर्कों के साथ फ़ंक्शन पास करते हैं। हम बस उनका उपयोग नहीं करते हैं। उदाहरण के लिए Array.prototype.forEach

फंक्शन करी के बारे में क्या? रामदास के साथ यह शायद बहुत अधिक सामान्य है
और लॉश/fp.

सोम, २९ फरवरी २०१६ को १३:४५ अनातोली रेसिन नोटिफिकेशन @github.com ने लिखा:

@sandersn https://github.com/sandersn , मुझे लगता है कि TypeError भी
कई तर्क कुछ ऐसा है जो जेएस की भावना का उल्लंघन करता है, जैसा कि हम
आम तौर पर वास्तविक तर्कों की तुलना में कम औपचारिक तर्कों के साथ फ़ंक्शन पास करते हैं
इस समारोह में पारित किया जाना है। हम बस उनका उपयोग नहीं करते हैं। उदाहरण के लिए
Array.prototype.forEach

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -190327066
.

@isiahmeadows मैं कहूंगा कि arguments.length पर आधारित करी बहुत अस्थिर और रनटाइम त्रुटि-प्रवण है। असली करी अतिरिक्त तर्क-सबूत है:

var plus = x => y => x + y
console.log(plus(3)(4)) // 7
console.log(plus(3,10)(4,20)) // still 7

जब मैं अपने फ़ंक्शन को निश्चित हस्ताक्षर के साथ कहीं पर कॉलबैक के रूप में पास करता हूं तो मैं इसके बारे में निम्नलिखित तरीके से सोचता हूं: 'मेरा कार्य _at कम से कम_ उन तर्कों की अपेक्षा करता है'

foldl जैसी चीज़ों के बारे में क्या?

const list = [1, 2, 3]
console.log(foldl((a, b) => a + b, 0, list))
console.log(foldl((a, b) => a + b, 0)(list))
console.log(foldl((a, b) => a + b)(0, list))
console.log(foldl((a, b) => a + b)(0)(list))

कार्यात्मक प्रोग्रामिंग में यह बहुत आम है। और आखिरी को छोड़कर
तर्क काफी सामान्य है।

सोम, २९ फरवरी २०१६ को, १३:५२ अनातोली राल नोटिफिकेशन @github.com ने लिखा:

@isiahmeadows https://github.com/isiahmeadows मैं कहूंगा कि करींग
aruments.length के आधार पर बहुत अस्थिर और रनटाइम त्रुटि-प्रवण है।
असली करी अतिरिक्त तर्क-सबूत है:

वर प्लस = x => y => x + y
कंसोल.लॉग(प्लस(3)(4)) // 7
कंसोल.लॉग(प्लस(3,10)(4,20)) // अभी भी 7

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment-190330620
.

यदि आप इसे कॉलबैक के रूप में पास करना चाहते हैं, तो कहें, map (एक सूची पर काम करना
सूचियों का), आप शायद इसे करी बनाना चाहेंगे।

सोम, २९ फरवरी २०१६ को, १३ :५९ [email protected] ने लिखा:

foldl जैसी चीज़ों के बारे में क्या?

const list = [1, 2, 3]
console.log(foldl((a, b) => a + b, 0, list))
console.log(foldl((a, b) => a + b, 0)(list))
console.log(foldl((a, b) => a + b)(0, list))
console.log(foldl((a, b) => a + b)(0)(list))

कार्यात्मक प्रोग्रामिंग में यह बहुत आम है। और आखिरी को छोड़कर
तर्क काफी सामान्य है।

सोम, २९ फरवरी २०१६ को, १३:५२ अनातोली रेजिन नोटिफिकेशन @github.com
लिखा था:

@isiahmeadows https://github.com/isiahmeadows मैं कहूंगा कि करींग
aruments.length के आधार पर बहुत अस्थिर और रनटाइम त्रुटि-प्रवण है।
असली करी अतिरिक्त तर्क-सबूत है:

वर प्लस = x => y => x + y
कंसोल.लॉग(प्लस(3)(4)) // 7
कंसोल.लॉग(प्लस(3,10)(4,20)) // अभी भी 7

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment-190330620
.

मुझे लगता है कि यह ज्यादातर इसके बारे में है:

type T = [number, string];
var a: T = [1, "a", 2]; // valid

// in this cases tuple types or parameter types cannot be inferred:
f(...a, true); // you could think number,string,boolean were passed, but weren't
const c = [...a, true]; // you could think that is of type [number, string, boolean] but it's not
// according to current rules, the best inferred types might be [number, string, number|string|boolean]

// same manner with variadic kinds, types are constructed properly:
type R = [...T, boolean]; // [number, string, boolean]

इसलिए मैंने #6229 . प्रस्तावित किया है

यह प्रश्न कि क्या [1, 2] [number] को संतुष्ट करता है, पूछने और बहस करने के लिए एक वैध प्रश्न है। लेकिन इसका स्प्रेडेबल टुपल्स फीचर से क्या लेना-देना है?

यह है कि क्या टुपल्स के एक विविध अनुप्रयोग को अतिरिक्त तर्कों को अनदेखा करना चाहिए
या नहीं। यह अतिभारित कार्य मेरी चिंता का अधिक विस्तार करना चाहिए।

declare function foo(x: number, ...args: string[]): void
declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

// This will always fail
declare function foo(x: number, ...args: string[]): void
declare function foo<T>(x: T): void
foo<number>(1, 2)

सोम, २९ फरवरी २०१६ को, १८:४७ जेसन फ्रीमैन नोटिफिकेशन @github.com ने लिखा:

[१, २] संतुष्ट [संख्या] का प्रश्न पूछने के लिए वैध है
और बहस। लेकिन इसका स्प्रेडेबल टुपल्स फीचर से क्या लेना-देना है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -190453352
.

और यही कारण है कि, व्यावहारिक कारणों से, मैं बाकी पैरामीटर की तरह पसंद करूंगा
विविध प्रकार।

सोम को, २९ फरवरी, २०१६, १९:०० इसिया मीडोज

यह है कि क्या टुपल्स के एक विविध अनुप्रयोग को अतिरिक्त अनदेखा करना चाहिए
तर्क या नहीं। इस अतिभारित फ़ंक्शन को my . के बारे में अधिक विस्तृत करना चाहिए
चिंता।

declare function foo(x: number, ...args: string[]): void


declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

// This will always fail
declare function foo(x: number, ...args: string[]): void
declare function foo<T>(x: T): void
foo<number>(1, 2)

सोम, २९ फरवरी २०१६ को, १८:४७ जेसन फ्रीमैन नोटिफिकेशन @github.com
लिखा था:

[१, २] संतुष्ट [संख्या] का प्रश्न पूछने के लिए वैध है
और बहस। लेकिन इसका स्प्रेडेबल टुपल्स फीचर से क्या लेना-देना है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -190453352
.

@JsonFreeman ऐसा इसलिए है क्योंकि प्रकार और सरणी/ A , B और T = [A] , तो फिर [...T, B] [A, B] निर्माण करेगा " (जो निहित रूप से प्रस्तावित है) तो इसे सरणी/टुपल स्प्रेड ऑपरेटर के साथ गठबंधन नहीं किया जाएगा। var a: [A] और var b: B को देखते हुए, अभिव्यक्ति के प्रकार [...a, b] को [A, B] प्रकार के रूप में साबित नहीं किया जा सकता है। टुपल्स के मौजूदा नियमों के अनुसार, इसे [A, A|B] प्रकार का साबित किया जा सकता है।
क्या यह आपके लिए समझ में आता है? या मैं उस बेमेल को उजागर करने के लिए तुलना तालिका बना सकता हूं।

@Igorbek मैं समझता हूं कि आप क्या कह रहे हैं। यह अंततः इस तथ्य से उपजा है कि संकलक को उन प्रकारों का पूर्ण ज्ञान है, जिनसे वह निपट रहा है, लेकिन मूल्यों का सही ज्ञान नहीं है। विशेष रूप से, आपके उदाहरण में, मान a की लंबाई अज्ञात है, जबकि प्रकार [A] की लंबाई ज्ञात है। यह एक कारण था कि मैं इस उद्देश्य के लिए टपल प्रकारों का उपयोग करने के बारे में शुरू में असहज था। लेकिन मुझे यकीन नहीं है कि यह एक गंभीर समस्या है।

@isiahmeadows मैं देख रहा हूँ कि आप किस बारे में पूछ रहे हैं, लेकिन बाकी प्रकार के मापदंडों के साथ कोई समस्या क्यों स्पष्ट है? यदि आपके पास प्रकार के तर्कों से अधिक तर्क हैं, तो वही प्रश्न पूछा जा सकता है।

सुरक्षित प्रकार का समाधान बाकी के साथ अधिक संगत होगा
भाषा अगर यह तर्क वाक्य रचना की नकल करती है।

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

मंगल, 1 मार्च, 2016, 06:07 को जेसन फ्रीमैन नोटिफिकेशन @github.com ने लिखा:

@Igorbek https://github.com/Igorbek मैं समझता हूं कि आप क्या कह रहे हैं।
यह अंततः इस तथ्य से उपजा है कि संकलक को पूर्ण ज्ञान है
यह किस प्रकार के साथ काम कर रहा है, लेकिन मूल्यों का सही ज्ञान नहीं है। में
विशेष रूप से, आपके उदाहरण में, मान की अज्ञात लंबाई है, जबकि
प्रकार [ए] की लंबाई ज्ञात है। यह एक कारण था कि मैं शुरू में था
इस उद्देश्य के लिए टपल प्रकारों का उपयोग करने में असहज। किंतु मुझे यकीन नहीं है
यह एक गंभीर समस्या है।

@isiahmeadows https://github.com/isiahmeadows मैं देख रहा हूं कि आप क्या पूछ रहे हैं
के बारे में, लेकिन बाकी प्रकार के मापदंडों के साथ समस्या कोई स्पष्ट क्यों है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -190667281
.

@isiahmeadows क्या आप करी समस्या के लिए उदाहरण कोड दे सकते हैं?

मुझे अभी भी लगता है कि भले ही आपने बाकी प्रकार के मापदंडों (जो मैं सभी के लिए हूं) का उपयोग किया हो, आपको स्पष्ट रूप से अतिरिक्त तर्कों की अनुमति नहीं देने का निर्णय लेना होगा, लेकिन मैं @isiahmeadows से सहमत

@sandersn @JsonFreeman

type FullCurry<T> = ((initial: T, xs: T[]) => T) | ((initial: T) => (xs: T[]) => T)
declare function foldl<T>(func: (acc: T, item: T) => T, initial: T, xs: T[]): T
declare function foldl<T>(func: (acc: T, item: T) => T): FullCurry<T>
declare function foldl<T>(func: (acc: T, item: T) => T, initial: T): (xs: T[]) => T

interface Function<T, R, ...A> {
    apply<U extends T>(inst: U, args: [...A]): R
    apply(inst: T, args: [...A]): R
}

function apply(reducer: (initial: number) => number): (number[]) => number {
    reducer.apply(undefined, [0, []])
}

const func = apply(foldl<number>((x, y) => x + y))

func([1, 2, 3]) // Runtime error

मैं अपनी विविधता भी जोड़ूंगा। आइए प्रस्ताव से विविध करी का उदाहरण देखें:

function curry<...T,...U,V>(f: (...ts: [...T, ...U]) => V, ...as:...T): (...bs:...U) => V {
    return ...b => f(...as, ...b);
}

तो फिर, मैंने इसका इस्तेमाल करना शुरू कर दिया:

function f(a: number, b: string, c: string) { return c.toUpperCase(); }
var a: [number, string] = [1, "boo", 2]; // valid
const cf = curry(f, ...a); // cf is of type string => string
cf("a"); // runtime error

@isiahmeadows चाहे उन्हें बाकी प्रकार के मापदंडों के रूप में या जताते हैं।

@Igorbek मुझे लगता है कि आपका उदाहरण समान है कि समस्या यह नहीं है कि विविध प्रकार के अनुक्रमों का प्रतिनिधित्व कैसे किया जाता है। यह उन्हें टुपल्स में फैलाने की क्षमता है जो समस्याओं की ओर ले जाती है।

@JsonFreeman यह अधिक है कि मुझे इस व्यवहार पर आपत्ति है:

class A {}
class B {}
class C {}

declare function foo(a: A, b: B): C;

// This should not work
let value: [A, B, C]
foo(...value)

क्या यह स्पष्ट करता है?

@isiahmeadows इसे वास्तव में काम करना चाहिए

@JsonFreeman
मुझे लगता है कि यह नहीं होना चाहिए। यही मेरी सबसे बड़ी आपत्ति है। मुझे लगता है कि अगर ऐसा है तो यह संभावित रूप से खतरनाक है।

प्रश्न: ret का अनुमानित रिटर्न प्रकार क्या होना चाहिए?

declare function foo(a: A, b: B, c: C, d: D): D
let ret = foo.bind(...[new A(), new B(), new D()])

यह वास्तव में काफी महत्वपूर्ण है।

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

उस ने कहा, ऐसा नहीं लगता है कि प्रस्तावित या चर्चा में कुछ भी इसे संभाल सकता है (चाहे टुपल्स के अतिरिक्त तर्कों की अनुमति है या नहीं), हालांकि यह संभव है कि मुझे कुछ याद आया।

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

@JsonFreeman

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

// I hate this idiom.
interface NestedArray<T> extends Array<Nested<T>> {}
type Nested<T> = T | NestedArray<T>

// I would much prefer this, but it requires non-strict type checking.
type Nested<T> = T | Nested<T>[]

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

शायद यही सबसे बड़ी बात है जो Function.prototype.bind की उचित टाइपिंग को रोक रही है, इस तथ्य के अलावा कि इसके लिए एक बहुत ही जटिल प्रकार के हस्ताक्षर की आवश्यकता होगी।

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

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

@JsonFreeman कहा जा रहा है, क्या आपको लगता है कि गोद लेने के तर्क के एक चरण के रूप में ऑपरेटर प्रस्ताव # 6229 को पहले विचार करने की आवश्यकता है?

@JsonFreeman

और प्रकारों की गैर-सख्त जांच पर्याप्त आलस्य को Function.prototype.bind साथ उस समस्या को ठीक करना आसान बनाने की अनुमति देगी। इस तरह के आलस्य के साथ, आप उस प्रकार को निम्नलिखित के साथ पूरा कर सकते हैं (जिसके लिए उन्हें अनुक्रमित करने के लिए एक टपल सिंटैक्स की आवश्यकता होगी, जब तक कि एक प्रकार की घोषणा में कई बाकी पैरामीटर ठीक न हों):

interface Function {
    bind<R, T, ...X, ...Y>(
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

इसका अनुमान लगाने के लिए गैर-सख्त प्रकार की जाँच की आवश्यकता क्यों होगी? फ़ंक्शन के विरुद्ध जाँच करने के लिए आपको बाकी प्रकार को चरण दर चरण घटाना होगा। निम्नलिखित को देखते हुए, यहां बताया गया है कि इसे कैसे जांचना होगा:

// Values
declare function func(a: number, b: string, c: boolean, d?: symbol): number

let f = func.bind(null, 1, "foo")

// How to infer
bind<R, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => R,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => R

// Infer first type parameter
bind<number, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => number,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer second type parameter
bind<number, any, ...X, ...Y>(
    this: (this: any, ...args: [...X, ...Y]) => number,
    thisObject: any,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer first part of rest parameter
bind<number, any, number, ...*X, ...Y>(
    this: (this: any, ...args: [number, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, ...*X]
): (this: any, ...rest: [...Y]) => number

// Infer second part of rest parameter
bind<number, any, number, string, ...*X, ...Y>(
    this: (this: any, ...args: [number, string, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, string, ...*X]
): (this: any, ...rest: [...Y]) => number

// First rest parameter ends: all ones that only uses it are fully spread
bind<number, any, number, string, ...Y>(
    this: (this: any, ...args: [number, string, ...Y]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [...Y]) => number

// Infer first part of next rest parameter
bind<number, any, number, string, boolean, ...*Y>(
    this: (this: any, ...args: [number, string, boolean, ...*Y]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, ...*Y]) => number

// Infer second part of next rest parameter
// Note that information about optional parameters are retained.
bind<number, any, number, string, boolean, symbol?, ...*Y>(
    this: (
        this: any,
        ...args: [number, string, boolean, symbol?, ...*Y]
    ) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, symbol?, ...*Y]) => number

// Second rest parameter ends: all ones that only uses it are exhausted
bind<number, any, number, string, boolean, symbol?>(
    this: (this: any, ...args: [number, string, boolean, symbol?]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, symbol?]) => number

// All rest parameters that are tuples get converted to multiple regular
parameters
bind<number, any, number, string, boolean, symbol?>(
    this: (
        this: any,
        x0: number,
        x1: string,
        x2: boolean,
        x3?: symbol
    ) => number,
    thisObject: any,
    x0: number,
    x1: string
): (this: any, x0: boolean, x1?: symbol) => number

// And this checks

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

let f = func.bind(null, 1, Symbol("oops"))

// How to infer
bind<R, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => R,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => R

// Infer first type parameter
bind<number, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => number,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer second type parameter
bind<number, any, ...X, ...Y>(
    this: (this: any, ...args: [...X, ...Y]) => number,
    thisObject: any,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer first part of rest parameter
bind<number, any, number, ...*X, ...Y>(
    this: (this: any, ...args: [number, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, ...*X]
): (this: any, ...rest: [...Y]) => number

// Infer second part of rest parameter
bind<number, any, number, string, ...*X, ...Y>(
    this: (this: any, ...args: [number, string, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, symbol /* expected string */, ...*X] // fail!
): (this: any, ...rest: [...Y]) => number

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

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

interface Function {
    apply<T, R, ...X>(
        this: (this: T, ...args: [...X]) => R,
        thisArg: T,
        args: [...X]
    ): R
}

कुछ अन्य नोट:

1. बाकी प्रकार के मापदंडों के रूप में सरणियों और टुपल्स को फैलाने का एक तरीका होना चाहिए।

ts interface Foo extends Function<void, ...string[]> {}

1. कंस्ट्रक्टर्स और कॉलेबल्स के लिए दो अलग-अलग प्रकार होने चाहिए, जिसमें फंक्शन्स दोनों का मिलन हो। कॉल करने योग्य ऑब्जेक्ट को कॉल करने योग्य इंटरफ़ेस को लागू करना चाहिए, क्लास कंस्ट्रक्टर को कंस्ट्रक्शनल इंटरफ़ेस को लागू करना चाहिए, और ES5 फ़ंक्शंस को दोनों के मिलन को लागू करना चाहिए।
2. Function.prototype.bind और दोस्तों को फ़ंक्शन के लिए सभी ओवरलोड के खिलाफ जांच करनी चाहिए। यदि कई काम हैं, तो उसे उन सभी का एक संघ वापस करना चाहिए।

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

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

interface SomeType<T, R, ...X, ...Y> {
     someMethod(someArgs): [...X]; // No way of knowing how long X is 
}

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

@JsonFreeman

_TL; DR: क्षैतिज रेखा विराम पर जाएं। मेरे पास एक नया, अधिक व्यावहारिक विचार है।_

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

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

interface Function<R, T, ...A> {
    // Split it up for just this method, since it's being resolved relative to the
    // method itself.
    bind[...A = ...X, ...Y](
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

एक संभावित अन्य समस्या है जिसे काम करना बहुत कठिन होगा (और मुझे क्यों लगता है कि इसे 2 तक सीमित किया जाना चाहिए, न कि _n _ डिवीजनों):

declare function foo<...T>[...T = ...A, ...B, ...C](
    a: [...A, ...C],
    b: [...A, ...B],
    c: [...B, ...C]
): any

// This should obviously check, but it's non-trivial to figure that out.
let x = foo<
    boolean, number, // ...A
    string, symbol,  // ...B
    Object, any[]  // ...C
>(
    [true, 1, {}, []],
    [true, 1, "hi", Symbol()],
    ["hi", Symbol(), {}, []]
)

_क्षमा करें यदि मैं यहाँ सीएस सिद्धांत में बहुत गहराई से जा रहा हूँ..._

हाँ, मुझे लगता है कि यह सही विचार है। यह बहुत नहीं है, लेकिन मैं किसी अन्य तरीके से नहीं सोच सकते हैं ठीक से टाइप करने के लिए bind , के प्रकार के तर्क जानने Function । अंतिम बात यह है कि एक सीमा का अनुमान लगाया जाना चाहिए। और मैं मानता हूं कि यह 2 बाल्टी तक सीमित होना चाहिए ताकि आपको कुछ मनमानी संख्या की सीमाओं के बजाय 1 सीमा का अनुमान लगाना पड़े, जो संयुक्त रूप से उड़ा सकती है।

ऐसे और भी मुद्दे हैं जिन पर हमने विचार नहीं किया है।

@JsonFreeman एक और मुद्दा curry जैसी चीजें हैं। मुझे अभी तक ऐसा कुछ नहीं मिला है जो इसे ठीक से टाइप कर सके। और इससे पहले कि मैं कर सकूं, इसमें कुछ समय लगेगा। ऐसी प्रक्रिया के साथ आने के लिए मुझे कुछ गंभीर हास्केल-जैसी प्रकार की हैकिंग करना होगा।

इस बारे में सोचना कि ब्लूबर्ड के कुछ कार्यों के साथ किस तरह का प्रस्ताव काम कर सकता है।

interface PromiseConstructor {
    // all same type
    all<T>(promises: PromiseLike<T>[]):  Promise<T[]>;
    join<T>(...promises: PromiseLike<T>[]):  Promise<T[]>;
    // varying types
    all<...T>(promises: [...PromiseLike<T>]): Promise<[...T]>;
    join<...T>(...promises: [...PromiseLike<T>]): Promise<[...T]>;
    // this is sketchy...    ^
}

interface Promise<T> {
    // all same type
    then<U>(onFulfill: (values: T) => U): Promise<U>;
    spread<U>(onFulfill: (...values: T) => U): Promise<U>;
}
interface Promise<...T> {
    // varying types
    then<U>(onFulfill: (values: [...T]) => U): Promise<U>;
    spread<U>(onFulfill: (...values: [...T]) => U): Promise<U>;
}

क्या हमारे पास उपरोक्त all<...T>(promises: [...PromiseLike<T>]): Promise<...T>; लिए कोई समाधान है?

@DerFlatulator

PromiseConstructor में मेरी बड़ी टिप्पणी देखें। मैंने अपने प्रस्ताव के थोड़ा करीब होने के लिए आपके प्रॉमिस इंटरफेस को भी ठीक किया है।

interface PromiseConstructor {
    new <T>(callback: (
        resolve:
        (thenableOrResult?: T | PromiseLike<T>) => void,
        reject: (error: any) => void
    ) => void): Promise<T, [T]>;
    new <...T>(callback: (
        resolve:
        (thenableOrResult?: [...T] | PromiseLike<[...T]>) => void,
        reject: (error: any) => void
    ) => void): Promise<[...T], ...T>;

    // all same type
    all<T>(promises: PromiseLike<T>[]):  Promise<T[], ...T[]>;
    join<T>(...promises: PromiseLike<T>[]):  Promise<T[], ...T[]>;

    // varying types
    all<...T>(promises: [...PromiseLike<T>]): Promise<[...T], ...T>;
    join<...T>(...promises: [...PromiseLike<T>]): Promise<[...T], ...T>;

    // all<...T>(promises: [...PromiseLike<T>]): Promise<[...T], ...T> should
    // expand to this:
    //
    // all<T1, T2, /* ... */>(promises: [
    //     PromiseLike<T1>,
    //     PromiseLike<T2>,
    //     /* ... */
    // ]): Promise<[T1, T2, /* ... */], T1, T2, /* ... */>;
    //
    // This should hold for all rest parameters, potentially expanding
    // exponentially like ...Promise<[Set<T>], ...Thenable<T>> which should
    // expand to something like this:
    //
    // Promise<[Set<T1>], Thenable<T1>, Thenable<T2> /* ... */>,
    // Promise<[Set<T2>], Thenable<T1>, Thenable<T2> /* ... */>,
    // // etc...
}

interface Promise<T, ...U> {
    // all same type
    then<V>(onFulfill: (values: T) => V): Promise<[V], V>;
    spread<V>(onFulfill: (...values: T) => V): Promise<[V], V>;

    // all same type, returns tuple
    then<...V>(onFulfill: (values: T) => [...V]): Promise<[...V], ...V>;
    spread<...V>(onFulfill: (...values: T) => [...V]): Promise<[...V], ...V>;

    // varying types
    then<V>(onFulfill: (values: [...U]) => V): Promise<[V], V>;
    spread<V>(onFulfill: (...values: [...U]) => V): Promise<[V], V>;

    // varying types, returns tuple
    then<...V>(onFulfill: (values: [...U]) => [...V]): Promise<[V], ...V>;
    spread<...V>(onFulfill: (...values: [...U]) => [...V]): Promise<[V], ...V>;
}

यदि [...Foo<T>] विस्तार [Foo<T1>, Foo<T2>, /*... Foo<TN>*/] , तो क्या [...Foo<T,U>] एक सिंटैक्स त्रुटि या एक संयोजनीय विस्तार है?

@DerFlatulator

1. यदि वास्तव में T या U से कोई एक बाकी पैरामीटर है, तो यह सामान्य रूप से फैलता है। मान लें कि T एक बाकी पैरामीटर है, तो यह [Foo<T1, U>, Foo<T2, U>, /*... Foo<TN, U>*/] ।
2. यदि दोनों बाकी पैरामीटर हैं, और उनकी लंबाई का सही अनुमान लगाया जा सकता है, तो यह एक संयोजनीय विस्तार होना चाहिए (अच्छी तरह से... टी की लंबाई यू की लंबाई)।
3. यदि न तो बाकी पैरामीटर हैं, तो यह एक सिंटैक्स त्रुटि है।

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

interface Function<R, T, ...A> {
    // Split it up for just this method, since it's being resolved relative to the
    // method itself.
    bind[...A = ...X, ...Y](
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

_(अगर कोई बेहतर वाक्य रचना के साथ आ सकता है, तो मैं सब कान हूं। मुझे यह पसंद नहीं है, लेकिन मैं ऐसा कुछ भी नहीं कर सकता जो दृष्टिगत रूप से विरोध न करे।)_

@isiahmeadows

2 के साथ, विस्तार किस क्रम में होगा?

[
Foo<T1, U1>, Foo<T2, U1>, /*... */ Foo<TN,U1>,
Foo<T1, U2>, Foo<T2, U2>, /*... */ Foo<TN,U2>,
/* ... */
Foo<T1, UN>, Foo<T2, UN>, /*... */ Foo<TN,UN>
]

या इसके विपरीत:

[
Foo<T1, U1>, Foo<T1, U2>, /*... */ Foo<T1,UN>,
Foo<T2, U1>, Foo<T2, U2>, /*... */ Foo<T2,UN>,
/* ... */
Foo<TN, U1>, Foo<TN, U2>, /*... */ Foo<TN,UN>
]

क्या यह अस्पष्टता भ्रम पैदा नहीं करेगी? शायद एक आयाम तक सीमित रहना ही समझदारी होगी।

स्प्लिट सिंटैक्स के लिए बस एक वैकल्पिक सुझाव:

interface Function<R, T, ...A> {
    bind<[...X, ...Y] = [...A]>(
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

@DerFlatulator

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

मैं इसे भी देख रहा हूं क्योंकि आप पहले के प्रत्येक भाग के लिए पहले, फिर दूसरे का विस्तार कर रहे हैं। इस स्यूडोकोड की तरह:

for (let TT of T) {
  for (let UU of U) {
    expand(TT, UU);
  }
}

उपरोक्त कुछ विचारों पर पुनरावृति ...

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TNewThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>
}

यहां, [...TBound, ...TUnbound] = [...TArgs] मान्य है क्योंकि ...TBound की लंबाई args की लंबाई से जानी जाती है। यह TThis के प्रकार को बदलने की भी अनुमति देता है।

इस दृष्टिकोण के साथ एक मुद्दा यह है कि आप केवल this एक बार बाइंड कर सकते हैं, उदाहरण के लिए:

interface IFoo { a: number }
interface IBar extends IFoo { b: boolean }
function f(a: number) { }

let x = f.bind(<IBar>{ a: 1, b: false }, 2); // inferred type: Function<number, IBar>
let y = x.bind(<IFoo>{ a: 1 }) // inferred type: Function<number, IFoo>

y का अनुमानित प्रकार गलत है, यह Function<number, IBar> होना चाहिए। मुझे यकीन नहीं है कि यह चिंता का विषय है या नहीं, लेकिन इसे हल करने के लिए <T> सिंटैक्स में तर्क पेश करने की आवश्यकता होगी।

विकल्प 1

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TNewThis = TThis is undefined ? TNewThis : TThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>;
}

विकल्प 2

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TThis is undefined,
        TNewThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>;

    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TThis is defined
    >(
        thisObject: any,
        ...args: [...TBound]
    ): Function<TReturn, TThis, ...TUnbound>;
}

हालाँकि यह संभवतः इस प्रस्ताव के दायरे से बाहर होगा।

मुझे नहीं लगता कि हमें टाइप स्प्रेड ऑपरेटर का उपयोग करके इस तरह के विस्तार की अनुमति देनी चाहिए। मैं स्प्रेड ऑपरेटर के बारे में "ब्रैकेट रिमूवर" के रूप में सोचता हूं जो सरणी स्प्रेड ऑपरेटर और ऑब्जेक्ट/प्रॉपर्टी स्प्रेड ऑपरेटर (चरण 2 प्रस्ताव) के साथ बिल्कुल गठबंधन है। बस तुलना करें:

let a =        [1, 2];
let b = [0, ...a     , 3];
//      [0, ...[1, 2], 3]
//      [0,     1, 2 , 3]  // removed brackets

let c =               { a: 1, b: "b" };
let d = { e: true, ...c               , f: 3 };
//      { e: true, ...{ a: 1, b: "b" }, f: 3 };
//      { e: true,      a: 1, b: "b"  , f: 3 };

आप इसे नए प्रकार के सेट के निर्माण के लिए विस्तारित करने का सुझाव दे रहे हैं:

<...T> = <A, B, C>
...U<T> = <U<A>, U<B>, U<C>>

यह पूरी तरह से अलग ऑपरेशन है। यदि आप चाहें, तो इसे उच्च क्रम के निर्माणों द्वारा तैयार किया जा सकता है जैसे कि:

<...(from R in T select U<R>)> // linq-like
<...(T[R] -> U<R>)> // ugly

@Igorbek यह निर्धारित करने के लिए कि क्या विस्तार किया जाएगा, एक ऑपरेटर का उपयोग करने के बारे में कैसे?

interface PromiseConstructor {
    all<
      ...T, 
      [...TThen] = ...(PromiseLike<@T> | @T)
    >(
      promises: [...TThen]
    ): Promise<[...T], ...T>;
}

जहां ...Foo<<strong i="9">@T</strong>, U> विस्तार [Foo<T1,U>, /*...*/, Foo<TN,U>] ।

...(PromiseLike<@T> | @T) फैलता है
[PromiseLike<T1>|T1, /*...*/, PromiseLike<TN>|TN]

कुछ वाक्यविन्यास विकल्प:

• ...Foo<&T,U>
• (T) Foo<T,U>
• (...T => Foo<T,U>)
• for (T of ...T) Foo<T,U>

मैं यहां @Igorbek से सहमत हूं। कम से कम इस स्तर पर, प्रकार के मानचित्रण अनुक्रम प्राथमिकता की तरह नहीं लगते हैं, यह देखते हुए कि हम अभी भी विविध प्रकार के मापदंडों की अधिक बुनियादी समस्या को हल करने का प्रयास कर रहे हैं।

मुझे इसे प्रतिबंधित करने में कोई समस्या नहीं है (कम से कम शुरुआत में), क्योंकि इसके लिए व्यवहार बहुत ही अनुपयुक्त है, और दो अलग-अलग लोग दो अलग-अलग चीजों की अपेक्षा कर सकते हैं, यहां तक ​​​​कि। मैं कम से कम अभी के लिए @Igorbek से सहमत हूं, क्योंकि टाइपस्क्रिप्ट को पहले एक उच्च-आदेश प्रकार मॉडल की आवश्यकता होती है (यह एक अर्थ में map पिंग एक प्रकार है)। और उच्च क्रम प्रकार बिल्कुल कुछ ऐसा नहीं है जिस पर आप बस बोल्ट कर सकते हैं।

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

थोड़ी देर से आ रहा हूं, लेकिन मैं @Igorbek से भी सहमत हूं। #1336 में की गई मेरी टिप्पणी को दोहराते हुए और स्पष्ट 'पैक' और 'अनपैक' ऑपरेटरों वाले सी ++ पैरामीटर पैकिंग से उधार विचार।

टुपल में पैकिंग प्रकार टाइपस्क्रिप्ट के स्प्रेड ऑपरेटर के उपयोग के अनुरूप लगता है:

let [x, y, ...rest] = [1, 2, 3, 4, 5] // pack
foo(...params) // unpack
let all = [1, 2, ...other, 5] // unpack

// keep in mind this is already implemented, which kind of similar to mapping types
function map(arr) { ... }
let spreadingmap = [1, 2, ...map(other), 5];

जिससे <...T_values> = [T1, T2, T3, etc...] बारे में तर्क करना बहुत आसान हो जाता है।

जबकि सी ++ पैकिंग के लिए स्प्रेड ऑपरेटर का उपयोग करता है और अनपैकिंग के लिए इलिप्सिस का उपयोग करता है, दोनों के लिए स्प्रेड का उपयोग टाइपस्क्रिप्ट के साथ अधिक संगत है।

module Promise {
  function all<...T_values>(   // pack into a tuple of types, conceptually identical to rest parameters
      values: [ (<PromiseLike<T*>> ...T_values) ]  // unpack, cast, then repack to tuple
  ): Promise<T_values> // keep it packed since T_values is a tuple of whatever types
}

@isiahmeadows @JsonFreeman बिना मैपिंग के इस

साथ ही जैसा कि #1336 में उठाया गया था, एक विविध Array.flatten बारे में कैसे?

@jameskeane वह पहला आधा प्रारंभिक विचार था, लेकिन इसमें मध्य आराम पैरामीटर (जो कुछ एपीआई हैं) के मामले को कवर नहीं करता है:

function foo<...T>(a: Foo, b: Bar, ...rest: [...T, Baz]): Foo;

यह Function.prototype.apply बनाम Function.prototype.call भी अच्छी तरह से कवर नहीं करता है।

#1336 के लिए, इसे इसी तरह से लागू किया जा सकता है:

angular.module('app').controller(['$scope', function($scope: ng.IScope) { /*etc...*/ }]);

interface IModule {
  controller(injectable: [...string[], () => any]);
}

मैंने पकड़ लिया है, और महसूस किया है कि मैं भोलेपन से मान रहा था कि टपल प्रकार सख्त लंबाई के थे; कौन सा आईएमओ सबसे सहज है। तो यह मानते हुए कि हमें सख्त लंबाई के टपल प्रकार (#6229) मिलते हैं, क्या मुद्दे हैं?

@isiahmeadows मध्य आराम पैरामीटर मामले के आपके उपरोक्त उदाहरण में, क्या यह सख्त लंबाई टुपल्स होने से हल नहीं होता है? मैं ...rest: [...T, Baz] को स्प्रेड अनपैकिंग के समान ही पढ़ रहा हूं arr = [...other, 123] । यह वही मुद्दा है जिसे आपने curry साथ उठाया था, है ना?

जहां तक apply और call , तो क्या वे प्रतिच्छेदन प्रकारों से आच्छादित नहीं हैं? (ऐसा नहीं है कि मैं वास्तव में Function इंटरफ़ेस पर वैसे भी प्रकार रखने में मूल्य देखता हूं)।

// as in
const t: [any, string] & [number, any] = [1, "foo"]

interface Function<R, T, ...A> {
    bind<...Y, ...Z>(
        this: (this: T, ...args: A & [...Y, ...Z]) => R, // tricky bit, luckily intersecting tuples is pretty easy
        thisObject: T,
        ...args: Y
    ): (this: any, ...rest: Z) => R
}

@jameskeane

वर्तमान विविध प्रस्ताव मानता है कि #6229 वास्तव में स्वीकृत हो जाता है (अर्थात टुपल्स डिफ़ॉल्ट रूप से सख्त होते हैं)।

func.apply , func.bind , func.call , और _.curry , केवल समस्या func.bind , _.curry , और दोस्तों, या अधिक आम तौर पर आंशिक आवेदन का उपयोग कर कुछ भी। आपको यह भी चुनने में सक्षम होना चाहिए कि कौन सा आराम पैरामीटर अलग करना है, और यह केवल प्रति-विधि के आधार पर ही किया जा सकता है।

call और apply बहुत सीधे हैं:

type Callable<R, T, ...A> = (this: T, ...args: [...A]) => R;

interface Function<R, T, ...A> {
    call(this: Callable<R, T, ...A>, thisArg: T, ...args: [...A]): R;
    apply(this: Callable<R, T, ...A>, thisArg: T, args: [...A]): R;
}

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

// Function.prototype.bind
type Callable<R, T, ...A> = (this: T, ...args: [...A]) => R;
type Constructible<R, ...A> = new (...args: [...A]) => R;

interface Function<R, T, ...A> {
    // my proposed syntax for splitting a rest parameter
    bind[[...A] = [...X, ...Y]](
        this: Callable<R, T, ...A>
        thisArg: T,
        ...args: [...X]
    ): Callable<R, any, ...Y>;

    bind[[...A] = [...X, ...Y]](
        this: Constructible<R, ...A>
        thisArg: T,
        ...args: [...X]
    ): Constructible<R, ...Y>;

    bind[[...A] = [...X, ...Y]](
        this: Callable<R, T, ...A> & Constructible<R, ...A>
        thisArg: T,
        ...args: [...X]
    ): Callable<R, T, ...Y> & Constructible<R, ...Y>;
}

curry बेहद मुश्किल होगा, क्योंकि यह जानना होगा कि f(1, 2, 3) === f(1, 2)(3) === f(1)(2, 3) === f(1)(2)(3) . न केवल बाकी पैरामीटर को दो में विभाजित करने की क्षमता होनी चाहिए जैसे bind , प्रति-विधि के आधार पर बहुत ही आदिम पैटर्न मिलान करने की क्षमता होनी चाहिए।

interface Curried<R, T, ...XS> {
    // none passed
    (): this;

    // all passed
    (this: T, ...args: [...XS]): R;
}

interface CurriedMany<R, T, X, ...YS> extends Curried<R, T, X, ...YS>  {
    // penultimate case, constraint that ...YS contains no parameters
    [[...YS] = []](arg: X): Curried<R, T, X>;

    // otherwise, split rest into ...AS and ...BS, with `A` used as the pivot
    // (basically, default case)
    [[...YS] = [...AS, A, ...BS]](
        ...args: [X, ...AS]
    ): CurriedMany<R, T, A, ...BS>;
}

function curry<R, T>(f: (this: T) => R): (this: T) => R;
function curry<R, T, X>(f: (this: T, arg: X) => R): Curried<R, T, A>;
function curry<R, T, X, ...YS>(
    f: (this: T, arg: X, ...args: [...YS]) => R
): CurriedMany<R, T, X, ...YS>;

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

@sandersn मैं ऊपर एक उदाहरण नहीं देख सका, लेकिन क्या मैं विविध मानकों पर बाधाओं के बारे में पूछ सकता हूं?

निम्नलिखित उदाहरण पर विचार करें:

interface HasKey<T> {
    Key(): T;
}

class Row<...T extends HasKey<X>, X> {
    // ...
}

_संयोग से, X को सूचीबद्ध करने की आवश्यकता को संभावित रूप से छोड़ने पर चर्चा के लिए https://github.com/Microsoft/TypeScript/issues/7848 देखें।

अब संभावित रूप से यहां कुछ अस्पष्टता है कि क्या बाधा है:

1. (...T) extends HasKey<X> या
2. ...(T extends HasKey<X>)

इस उदाहरण में मैं 2 मान रहा हूँ।

क्या इस प्रकार की बाधाएं (1 और/या 2) संभव होंगी?

@myitcv 2 शायद जाने का सबसे अच्छा मार्ग होगा, लेकिन बाधा की जांच के लिए मौजूदा तर्क का पुन: उपयोग करना समझ में आता है।

अच्छा ... मुझे अभी कुछ एहसास हुआ: विविध प्रकार वाले सरणी कैसे होंगे? या अधिक विशेष रूप से, नीचे arg किस प्रकार का है?

function processItems<...T>(...args: [...T]): void {
    for (const arg of args) { // Here
        process(arg);
    }
}

मुझे लगता है कि आप पूछ रहे हैं कि args का तत्व प्रकार क्या है। टुपल्स के लिए, मेरा मानना ​​​​है कि यह आमतौर पर तत्वों का संघ प्रकार है। मैं इसे टाइप करने के बेहतर तरीके के बारे में नहीं सोच सकता।

@sandersn क्या आप टिप्पणी कर सकते हैं कि इस सुविधा की स्थिति क्या है? मुझे लगता है कि बहुत चर्चा हुई है, लेकिन ऐसा नहीं लगता कि फीचर के लिए कोई निश्चित योजना है, क्या यह सही है?

@JsonFreeman मैं विशेष रूप से पूछ रहा था कि arg था। मेरी राय में, यह मेरे मूल उदाहरण के लिए any होना चाहिए, और नीचे के साथ Item<T> (एफ-बाउंडेड टी के साथ):

function processItems<...T extends Item<T>>(...args: [...T]): void {
    for (const arg of args) { // Here
        process(arg);
    }
}

ऐसा इसलिए है ताकि स्थानीय रूप से प्रकारों को हल किया जा सके। आप पहले से प्रकारों को नहीं जानते हैं, और यह संकलन को बहुत तेज कर देगा, क्योंकि आपको प्रत्येक कॉल के लिए फ़ंक्शन के भीतर प्रकारों की गणना करने की आवश्यकता नहीं है। ध्यान दें कि यदि आपको केवल एक तर्क के प्रकार की आवश्यकता है, तो typeof arg पर्याप्त होगा, और संभवतः छोटा होगा।

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

मेरा मतलब दूसरे में Item<any> था...क्षमा करें।

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

लेकिन मोटे तौर पर, मैं उत्सुक हूं कि टीम 2.0 के बाद इस सुविधा पर कितनी सक्रियता से विचार कर रही है। मेरी कोई मजबूत राय नहीं है, बस सोच रहा हूं।

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

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

// To put it into code
function foo<...T>(list: [...T]): void {
    // This is allowed
    let xs: T[] = list

    // This is allowed
    let list2: [...T] = list

    // This is not allowed
    let list1: [...T] = xs

    // This is allowed
    let item: ?T = null

    // This is not allowed, since it's not immediately initialized
    let other: T

    for (let arg of args) {
        // This is allowed
        let alias: T = arg

        // This is allowed
        let other: ?T = arg

        // This is allowed, since `item` is defined upwards as `?T`
        item = arg

        // This is allowed, since you're doing an unsafe cast from `?T` to `T`.
        alias = item as T
    }
}

हालांकि, यह शायद अधिक समझ में आता है, और यह अधिक लचीला होगा।

यह अभी भी हमारी अच्छी सूची में है, लेकिन यह मुख्य रूप से पुस्तकालय लेखकों के लिए रुचि रखता है और इसका एक अच्छा समाधान है - _n_ अधिभार - इसलिए मैं इस पर सक्रिय रूप से काम नहीं कर रहा हूं। अगर मुझे अनुमान लगाना होता, तो मैं कहूंगा कि 2.1 संभव है लेकिन संभावना नहीं है।

यदि/जब हम ऑब्जेक्ट रेस्ट/स्प्रेड (#2103) का ठीक से समर्थन करने के लिए प्रतिबद्ध हैं, तो वेरिएडिक प्रकार उन सभी को एक साथ करने का औचित्य साबित करने के लिए प्रकार फैलाने के लिए पर्याप्त हो सकते हैं। (स्प्रेड प्रकार ऑब्जेक्ट प्रकारों का एक प्रकार है जो { ...T, x: number, ...U, y: string, ...V } जैसा दिखता है।)

केवल यह उल्लेख करना चाहता हूं कि n overloads वर्कअराउंड कक्षाओं या इंटरफेस के लिए काम नहीं करता है, जो इस सुविधा में मेरी विशेष रुचि है।

@sandersn क्या bind , apply और call this टाइपिंग का उपयोग करके "_n_ ओवरलोड" के लिए एक पुल अनुरोध आमंत्रित किया जाएगा? मुझे लगता है कि यह कई लोगों के लिए एक स्वीकार्य अस्थायी समझौता होगा, और कुछ परियोजनाओं के लिए प्रक्रिया में कुछ बग पकड़ सकता है।

@isiahmeadows

कारण मुझे नहीं लगता कि यह जरूरी टी होना चाहिए क्योंकि आप नहीं जानते कि टी क्या है।

मुझे ऐसा लग रहा था कि इस बात पर सहमति है कि T एक प्रकार का वैरिएडिक प्रकार है। आपके मूल उदाहरण में, arg प्रकार टुपल तत्व प्रकार के समान होगा (जैसा कि

function processItems<...T>(...args: T): void {
  for (const arg of args) { // Here - arg:number|string|boolean
    const other: ??? = arg; // I think the issue is, how to _represent_ this type?
  }
}
processItems(1, 'foo', false); // T is tuple [number, string, boolean]

इस प्रस्ताव से अलग, मुझे लगता है कि टुपल के 'तत्व प्रकार' का प्रतिनिधित्व करने का एक तरीका होना चाहिए। यह प्रसार के लिए एक और उपयोग हो सकता है, अर्थात ...T :: number|string|boolean ; जो टुपल प्रकार को फैलाने के परिणामस्वरूप इसके तत्व प्रकार में परिणाम देता है।

for (const arg of args) {
  const cst: ...T = arg;
}

// also, even without variadic types...
type Record = [number, string];
function foo(args: Record) {
  for (const arg in args) {
    const cst: ...Record = arg;
  }
}

इसे ध्यान में रखते हुए, आपके अन्य उदाहरण:

function foo<...T>(...list: T): void {
  let xs: T[] = [list, list] // array of the variadic tuple type

  // This is allowed
  let list5: (...T)[] = [...list]

  // This is *not* allowed
  let list2: [...T] = list

  // This is not allowed
  let list1: [...T] = xs

  // This **is** allowed
  // single element tuple, of variadic union
  // i.e. with number|string|boolean
  //      list4 = [1] or list4 = ['foo'] or list4 = [false]
  let list4: [...T] = [list[n]]

  // This **is**  allowed
  let other: T;

  // This is allowed
  let another: ...T;

  for (let arg of args) {
    another = arg; // allowed, if spreading the tuple is the union type

  }
}

अपने मूल लक्ष्य की दृष्टि न खोते हुए, मैं दृढ़ता से टाइप किया हुआ Promise.all चाहता था ...

declare module Promise {
  function all<...T>(promises: Promise<...T>[]): T; // means promises is an array of promises to the union type, not what I wanted.

  // Then we need something like, which is now very confusing
  function all<...T>(promises: [...Promise<T*>]): T; 
}}

@sandersn अब जबकि अन्य अनुरोधित सुविधाएँ इस पर निर्भर होने बढ़ाया जा सकता है? bind , call आदि टाइपिंग इस पर निर्भर करती है, और ES बाइंड सिंटैक्स अगर/जब यह बाहर आता है तो उस पर निर्भर करता है, इसलिए अब इस पर अधिक सवारी है विचित्र पुस्तकालय लेखक आपको हर समय परेशान करते हैं . :)

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

क्या इसका उपयोग _.extend लिए एक पूर्ण प्रकार की परिभाषा प्रदान करने के लिए किया जा सकता है, जिसका रिटर्न प्रकार इसके सभी मापदंडों का प्रतिच्छेदन है?

declare module underscore {
  function extend<A, B, C, D, ...>(a: A, b: B, c: C, d: D, ...): A&B&C&D&...;
}

जैसा खड़ा है वैसा नहीं। इसे उस प्रस्ताव के विस्तार की आवश्यकता है जो विविध प्रकार के लिए एक नए ऑपरेटर पर विवरण देता है - जिसे शायद & कहा जाता है। @kitsonk ने इस ऑपरेटर को पहले इस टिप्पणी में प्रस्तावित किया था।
अभी यह सुविधा कुछ अन्य तत्काल महत्वपूर्ण चीजों के नीचे है इसलिए मैंने कुछ समय में इस प्रस्ताव को नहीं देखा है।

पूर्ण विविध प्रकार प्रदान नहीं करते हुए, #10727 समाधान का हिस्सा है (और हमारे पास (@dojo) की चुनौतियों का समाधान करने की संभावना है)।

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

interface Object {
  // binary version
  assign<T,U>(target: T, source: U): { ...T, ...U };
  // variadic version: bind a variadic kind variable ...T
  // and then spread it using SIX dots
  assign<...T>(...targets: ...T): { ......T };
}

ध्यान दें कि "सिक्स डॉट्स" सिंटैक्स एक टपल प्रकार के चर का ऑब्जेक्ट स्प्रेड है, जिसकी हमने वास्तव में ऊपर चर्चा नहीं की है।

@sandersn

विशेष रूप से Object.assign साथ, इसे इस तरह से टाइप किया जा सकता है, और तकनीकी रूप से एक सबसेट को कैप्चर

assign<T>(target: T, ...sources: Partial<T>[]): T;

इसके साथ गड़बड़ यह है कि यह अपने लक्ष्य को बदल देता है, इसके संरचनात्मक प्रकार को जगह में बदल देता है।

@isiahmeadows तब अनुमान T को target प्रकार के रूप में sources लेखांकन प्रकारों के बिना ठीक कर देगा। आप इसे अब गैर-वैरिएडिक संस्करण के साथ आज़मा सकते हैं:

declare function _assign<T>(target: T, source: Partial<T>): T;
_assign({}, { a: 10 }); // T is {}

जैसा कि पहले ही उल्लेख किया गया है, assign _a स्प्रेड प्रकार_ #10727 का उपयोग करता है और इसे इस तरह परिभाषित किया जा सकता है:

// non variadic
declare const assign: {
  <T>(target: T): T;
  <T, S>(target: T, source: S): {...T, ...S};
  <T, S1, S2>(target: T, source1: S1, source2: S2): {...T, ...S1, ...S2};
};
// variadic
declare function assign<T, [...S]>(target: T, ...sources: [...S]): {...T, ...[...S]};

_नोट: मैं अभी भी टपल-आधारित सिंटैक्स पर जोर दे रहा हूं [...T] जो मेरे लिए बहुत अधिक समझ में आता है।_

@sandersn BTW, क्या कोई अपडेट है जब विविध प्रकार के उतरने वाले हैं? क्या इसे 2.2 में देखने का कोई मौका है?
और, वाक्य रचना के संबंध में, क्या आप अभी भी वाक्य रचना पर प्रतिक्रिया स्वीकार करते हैं या आप सभी इससे सहमत हैं?

वाक्य रचना और निम्न स्तर के शब्दार्थ में अभी तक कोई स्पष्ट सहमति नहीं है।

मंगलवार, 13 दिसंबर 2016 को, 13:26 इगोर ओलेनिकोव नोटिफिकेशन @github.com ने लिखा:

@sandersn https://github.com/sandersn BTW, कब पर कोई अपडेट है?
विविध प्रकार के उतरने जा रहे हैं? क्या इसे 2.2 में देखने का कोई मौका है?
और, वाक्य रचना के संबंध में, क्या आप अभी भी वाक्य रचना पर प्रतिक्रिया स्वीकार करते हैं या
आप सब इससे सहमत हैं?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment-२६६८१ ९
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AERrBIa5fE8PSk-33w3ToFqHD9MCFoRWks5rHuM5gaJpZM4GYYfH
.

इस मुद्दे की स्थिति क्या है इस पर कोई विचार?

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

एक Tuple extends any[] सुपरटाइप जोड़ना आसान होगा जिसे केवल टपल प्रकारों द्वारा उप-प्रकार किया जा सकता है। चूंकि स्प्रेड any[] उपप्रकार होने चाहिए, यह काम करेगा:

declare interface Plugin<A: Tuple, P> {
  (...args: A): P | Promise<P>
}

const p: Plugin<[string, { verbose: boolean }], int> =
  (dest, { verbose = false }) => 4

फिलहाल, ...args: T[] की अनुमति केवल हस्ताक्षर के अंत में दी जाती है।

जटिल उपयोग के मामले को हस्ताक्षर के अंदर कहीं भी कानूनी होने के लिए ...args: Tuple आवश्यकता होगी (जो कोई समस्या नहीं है, क्योंकि टुपल्स निश्चित-लंबाई वाले हैं):

/**
 * Takes a function with callback and transforms it into one returning a promise
 * f(...args, cb: (err, ...data) => void) => void
 * becomes
 * g(...args) => Promise<[...data]>
 */
function promisify<A extends Tuple, D extends Tuple, E>
    (wrapped: (...args: A, cb: (error: E, ...data: D) => void) => void)
    : ((...args: A) => Promise<Data>) {
  return (...args) => new Promise((resolve, reject) =>
    wrapped(...args, (e, ...data) =>
      e ? reject(e) : resolve(data)))
}

const write: ((fd: number, string: string, position?: number, encoding?: string)
              => Promise<[number, string]>) =
  promisify(fs.write)

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

function portable(func) {
    return function(...args) {
        if (this === undefined) {
            return func(...args)
        } else {
            return func(this, ...args)
        }
    }
}

प्रभावी रूप से सभी डेकोरेटर एक फ़ंक्शन को एक विधि के रूप में भी कॉल करने की अनुमति देता है ताकि उन्हें एक विधि के रूप में जोड़ा जा सके और समान रूप से काम किया जा सके, मूल उदाहरण के रूप में यहां एक खराब उदाहरण है जो Array प्रोटोटाइप को पैच करता है flatMap मूल संस्करण के साथ:

function _flatMap<T, R>(
    array: T[],
    iteratee: (item: T) => R[]
): R[] {
    let result: R[] = []
    for (const item of array) {
        for (const value of iteratee(item)) {
            result.push(value)
        }
    }
    return result
}

const flatMap = portable(_flatMap)
Array.prototype.flatMap = flatMap

flatMap([1,2,3,4], x => [x, x])
// Is the same as
[1,2,3,4].flatMap(x => [x, x])
// Is the same as
flatMap.apply([1,2,3,4], [x => [x, x]])
// Is the same as
flatMap.call([1,2,3,4], x => [x, x])

अब उम्मीद है कि यह स्पष्ट है कि flatMap ( _flatMap ) का प्रकार है:

function flatMap<T, R>(this: T[], iteratee: (item: T) => R[]): R[]
function flatMap<T, R>(this: undefined, array: T[], iteratee: (item: T) => R[]): R[]

हालांकि मेरे पास पोर्टेबल में types जोड़ने का कोई तरीका नहीं है क्योंकि मैं पैरामीटर प्रकार को _flatMap से नहीं निकाल सकता, फिर सजाए गए फ़ंक्शन की प्रकार परिभाषा के भीतर उपयोग कर सकता हूं, मैं इस प्रस्ताव के साथ कल्पना कर सकता हूं कुछ इस तरह लिखें:

// First argument to func is required for portable to even make sense
function portable<T, R, ...Params>(func: (first: T, ...rest: Params) => R) {
    // The arguments of calling with this is undefined should be simply
    // exactly the same as the input function
    function result(this: undefined, first: T, ...rest: Params): R
    // However when this is of the type of the first argument then the type
    // should be that the parameters are simply the type of the remaining
    // arguments
    function result(this: T, ...rest: Params): R
    function result(...args) {
        if (this === undefined) {
            return func(...args)
        } else {
            return func(this, ...args)
        }
    }
    return result
}

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

@sandersn :

इसका एक अच्छा समाधान है - n अधिभार

जबकि तकनीकी रूप से गलत नहीं है, मुझे लगता है कि यह यहां की वास्तविकता को पूरी तरह से प्रतिबिंबित नहीं करता है। हाँ, तकनीकी रूप से इसकी कमी ओवरलोड को इस धागे में उल्लिखित किसी भी फ़ंक्शन को टाइप करने से नहीं रोक सकती है; और फिर भी, इस छोटी सी असुविधा का मतलब है कि इस तरह के किसी भी अधिभार-आधारित समाधान ने इसे अब तक lib.d.ts नहीं बनाया है।

और वास्तव में, इस थ्रेड में कई लोगों ने अपने संबंधित कार्यों से निपटने के लिए काफी हताश महसूस किया है ताकि मूल रूप से इस प्रस्ताव का हिस्सा न होने वाले और भी सिंटैक्स का प्रस्ताव दिया जा सके, जिसमें आपके ...... , साथ ही साथ ...*X , [...T = ...A, ...B, ...C] , [...PromiseLike<T>] , <[...X, ...Y] = [...A]> , और <PromiseLike<T*>> ।

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

साइड नोट: रामदा के R.path हमने ओवरलोड की हजार-ईश लाइनों की एक टाइपिंग उत्पन्न की थी, जो अभी भी टपल समर्थन से चूक गई थी (क्रमपरिवर्तन अभी भी कठिन तरीके से विस्फोट हो गया होगा), और वास्तविक परियोजनाओं पर संकलन को समाप्त नहीं करने का कारण बना अब और। हाल ही में वहां एक व्यवहार्य विकल्प के रूप में पुनरावृत्ति की खोज की गई (#12290)।

वैसे, आपने अभी तक @Artazor और @Igorbek द्वारा निर्धारित प्रस्ताव पर टिप्पणी नहीं की है। उस पर आपके क्या विचार थे?

मैं इस तरह के बुनियादी कार्यान्वयन के साथ बहस करना चाहता हूं (प्लस # 6606) हम कुछ भी कर सकते हैं। मैं इसे स्पष्ट करने के लिए यहां कुछ समाधान प्रस्तुत करूंगा, लेकिन मैं आगे के प्रश्नों के लिए तैयार हूं।

मुझे पहले कुछ स्थानों पर जाने दें जहां एक ... ऑपरेटर लागू किया जा सकता है:

v ... लिए | परिभाषा (कैप्चर) | उपयोग (फैलाना)
-|-|-
समारोह | type Fn = (...args: any[]) => {} | type Returns = typeof fn(...MyTuple); (#6606)
सरणी | टाइप-लेवल टपल डिस्ट्रक्टिंग। इंडेक्स एक्सेस + स्प्रेड (दाएं देखें) + रिकर्सन का उपयोग करके तकनीकी रूप से अनुकरण किया जा सकता है। | type Arr = [Head, ...Tail];
वस्तु | टाइप-लेवल ऑब्जेक्ट डिस्ट्रक्टिंग। आवश्यक नहीं है, बस Omit , #12215 देखें। | type Obj = { a: a, ...restObj }; (आवश्यक नहीं, Overwrite , #12215 देखें)
जेनरिक | type Foo<...T> को Foo<1, 2, 3> type Foo<...T> करने के लिए परिभाषित करें (कैप्चर करता है [1, 2, 3 ] में T )। मज़ा, लेकिन यह नहीं पता कि किस उपयोग-मामले के लिए इसकी आवश्यकता है। | type Bar<A,B,C> को Bar<...[1,2,3]> ( A = 1 आदि) करने के लिए परिभाषित करें। डिट्टो, उन उपयोग-मामलों के बारे में नहीं जानते जिन्हें इसकी आवश्यकता है ।
यूनियनों (बोनस) | ? | type Union = "a" | "b"; type MyTuple = ...Union; // ["a", "b"] (आदेश अविश्वसनीय है लेकिन टुपल्स के माध्यम से यूनियनों/वस्तुओं के पुनरावृत्ति को सक्षम बनाता है। वैसे भी, यहां गुंजाइश से बाहर है।)

तो केवल दो प्रकार-स्तर ... उदाहरण हैं जो तत्काल प्रासंगिक हैं; विशेष रूप से, दोनों का उपयोग यहाँ किया गया है:

declare function f<U, T>(head: U, ...tail: T): [U, ...T];

#6606 के संदर्भ में, दूसरा प्रासंगिक हो जाता है: फ़ंक्शन एप्लिकेशन के लिए टपल प्रकार को अनपैक करने की क्षमता, जैसे typeof f(...MyTuple) । मुझे लगता है कि ये उन कठिन समस्याओं को हल करने के लिए पर्याप्त हैं जिनका मैंने यहां उल्लेख किया है। यहां कुछ समाधान पेश करने का प्रयास करने के लिए:

@jameskeane :

मुझे लगता है कि टपल के 'तत्व प्रकार' का प्रतिनिधित्व करने का एक तरीका होना चाहिए

यदि आप उनके तत्वों का संघ प्राप्त करना चाहते हैं, तो मेरा TupleToUnion ।

Promise.all

// helpers: `mapTuple` needs #5453 to define, #6606 to use
type TupleHasIndex<Arr extends any[], I extends number> = ({[K in keyof Arr]: '1' } & Array<'0'>)[I];
type Inc = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; // longer version in gist
declare function mapTuple<F extends (v: T) => any, Tpl extends T[], T>(f: F, tpl: Tpl): MapFn<F, Tpl, T>;
type MapFn<
    F extends (v: T) => any,
    Tpl extends T[],
    T,
    // if empty tuple allowed:
    // I extends number = 0,
    // Acc = []
    // otherwise:
    I extends number = 1,
    Acc = [F(Tpl[0])]
> = { 1: MapFn<F, Tpl, T, Inc[I], [...Acc, F(Tpl[I])]>; 0: Acc; }[TupleHasIndex<Tpl, Int>];

declare module Promise {
  function all<Promises extends Promise<any>[]>(promises: Promises): typeof mapTuple(<T>(prom: Promise<T>) => T, Promises);
}

@दानवक :

_.extend

@sandersn :

Object.assign

ये दोनों रामदा के mergeAll केवल भिन्न संस्करण हैं। कोई छह डॉट्स की जरूरत नहीं है!

@isiahmeadows :

इस मुद्दे की स्थिति क्या है इस पर कोई विचार?
वाक्य रचना और निम्न स्तर के शब्दार्थ में अभी तक कोई स्पष्ट सहमति नहीं है।

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

// helpers in https://gist.github.com/tycho01/be27a32573339ead953a07010ed3b824, too many to include

// poor man's version, using a given return value rather than using `typeof` based on the given argument types:
function curry<Args extends any[], Ret>(fn: (...args: Args) => Ret): Curried<Args, Ret>;
type Curried<
  ArgsAsked,
  Ret,
  ArgsPrevious = [] // if we can't have empty tuple I guess any[] might also destructures to nothing; that might do.
> = <
  ArgsGiven extends any[] = ArgsGiven,
  ArgsAll extends [...ArgsPrevious, ...ArgsGiven]
      = [...ArgsPrevious, ...ArgsGiven]
  >(...args: ArgsGiven) =>
    If<
      TupleHasIndex<ArgsAll, TupleLastIndex<ArgsAsked>>,
      Ret,
      Curried<ArgsAsked, Ret, ArgsAll>
    >;

// robust alternative that takes into account return values dependent on input params, also needs #6606
function curry<F>(fn: F): Curried<F>;
type Curried<
  F extends (...args: ArgsAsked) => any,
  ArgsAsked extends any[] = ArgsAsked,
  ArgsPrevious = []
> = <
  ArgsGiven extends any[] = ArgsGiven,
  ArgsAll extends [...ArgsPrevious, ...ArgsGiven]
      = [...ArgsPrevious, ...ArgsGiven]
  >(...args: ArgsGiven) =>
    If<
      TupleHasIndex<ArgsAll, TupleLastIndex<ArgsAsked>>,
      F(...[...ArgsPrevious, ...ArgsGiven]),　// #6606
      Curried<ArgsAsked, Ret, ArgsAll>
    >;

// bind:
interface Function {
    bind<
        F extends (this: T, ...args: ArgsAsked) => R,
        ArgsAsked extends any[],
        R extends any,
        T,
        Args extends any[], // tie to ArgsAsked
        Left extends any[] = DifferenceTuples<ArgsAsked, Args>,
        EnsureArgsMatchAsked extends 0 = ((v: Args) => 0)(TupleFrom<ArgsAsked, TupleLength<Args>>)
        // ^ workaround to ensure we can tie `Args` to both the actual input params as well as to the desired params. it'd throw if the condition is not met.
    >(
        this: F,
        thisObject: T,
        ...args: Args
    ): (this: any, ...rest: Left) => R;
    // ^ `R` alt. to calc return type based on input (needs #6606): `F(this: T, ...[...Args, ...Left])`
}

हाँ, मैंने सहायक प्रकारों का एक समूह इस्तेमाल किया - बस हमारे पास जो कुछ है उसके साथ करने की कोशिश कर रहा है (+ कल्पना करें कि हम थोड़ा और क्या कर सकते हैं)। मैं ...... , ...*X , [...T = ...A, ...B, ...C] , [...PromiseLike<T>] , <[...X, ...Y] = [...A]> , या <PromiseLike<T*>> खिलाफ इतना अधिक नहीं हूं। लेकिन आईएमओ, यहां तक ​​​​कि सिर्फ ... अभी एक वास्तविक मुद्दे को हल करने में मदद करता है, और मुझे इसे संबोधित करते हुए देखना अच्छा लगेगा।

संपादित करें: मैंने bind लिए तर्क बाधा हल की।

बस शायद बेवकूफी भरा सवाल। यह करी कार्यों को सही ढंग से टाइप करने में सक्षम होने के लिए बहुत ही आशाजनक दिखता है।
लेकिन कुछ वास्तविक दुनिया की परियोजनाओं के लिए, कोई भी भारी कार्यात्मक प्रोग्रामिंग उन्मुख कोड के टुकड़े को टाइप करने के लिए ज्यादा समय नहीं देना चाहता था।
इसलिए, मैं सोच रहा हूं, क्योंकि --strict डिफ़ॉल्ट रूप से _tsconfig.json_ में सक्षम है, अगर कोड के एक हिस्से के लिए टाइप-चेकिंग को अक्षम करने का कोई तरीका हो सकता है (आलस्य या समय की कमी के कारण)।
लेकिन, जैसा कि मैंने कहा, यह शायद एक बेवकूफी भरा सवाल है... ^_^

@ yahiko00 तरह का विषय, लेकिन exclude अनुभाग में tsconfig या विभिन्न परियोजना स्तरों पर अलग tsconfig s का उपयोग करें।

मैं एक और सुझाव भी देना चाहूंगा, क्या हमारे पास ऐसा हो सकता है ताकि & और | इस सिंटैक्स के साथ एकल टपल तर्क के साथ काम करें:

<...T>(...args:T): ...T&
// is the same as 
<t1, t2, t3>(...args:[t1, t2, t3]): t1 & t2 & t3;
// and
<....T>(...args:T): ...T|
// is the same as 
<t1, t2, t3>(...args:[t1, t2, t3]): t1 | t2 | t3;

@HyphnKnight का उपरोक्त सुझाव उस चीज़ के लिए बहुत उपयोगी होगा जो मैं भी कर रहा हूँ।

मैं एक अस्वीकरण जोड़ना चाहता हूं कि इस प्रस्ताव पर सक्रिय रूप से काम नहीं किया जा रहा है। लेकिन जब मैंने पहली बार इस समस्या को देखना शुरू किया तो मुझे ठीक उसी तरह का "पूर्व कला" का पेपर मिला, जिसे मैं पढ़ना चाहता था: http://www.ccs.neu.edu/racket/pubs/esop09-sthf.pdf

मैं इसे भविष्य के संदर्भ के लिए यहाँ छोड़ दूँगा।

मैंने इस दिशा में प्रयोग करते हुए कुछ पीआर खोले:

• [ ] #17884 टपल प्रकारों में फैलता है (WIP)
• [x] #१७८९८ बाकी पैरा निकालें (तैयार)
• [ ] #१८००७ टाइप कॉल (डब्ल्यूआईपी) में फैलता है

const c = 'a' + 'b';

समस्या का समाधान कर सकते हैं? अनुमान प्रकार का c 'ab' न कि string

StackOverflow पर संबंधित प्रश्न: टाइपस्क्रिप्ट में स्पष्ट अंतिम फ़ंक्शन पैरामीटर

@sandersn आप प्रस्ताव इस मामले को कवर करेंगे, जहां तक ​​​​मैं देख सकता हूं, क्या यह सही है?

प्रारंभिक प्रस्ताव के 2 साल से अधिक समय से, क्या हमें अभी भी आशान्वित रहना चाहिए?

नमस्कार!
मैं एक जनरेटर टाइप करने की कोशिश कर रहा हूं जो सरणी की एक चर संख्या लेता है और एक नई सरणी बनाने के लिए उनमें से तत्वों को मिलाता है और मेल खाता है।
मैं इस जनरेटर का उपयोग for...of लूप में करना चाहता हूं, लेकिन मूल्यों की उचित टाइपिंग नहीं कर सकता।
कोड (गलतियां हो सकती हैं क्योंकि मैंने इसे अभी तक नहीं चलाया है, लेकिन यही वह है जो मैं करने की कोशिश कर रहा हूं):

function* CombineEveryArgumentWithEveryArgument(...args: any[][]) {
    if (args.length < 1) {
        return [];
    }
    var haselements = false;
    for (var arg of args) {
        if (arg && arg.length > 0) {
            haselements;
        }
    }
    if (!haselements) {
        return [];
    }
    var indexes = [];
    for (var i = 0; i < args.length; i++) {
        indexes.push(0);
    }
    while (true) {
        var values = [];
        //One item from every argument.
        for (var i = 0; i < args.length; i++) {
            values.push(args[i][indexes[i]]);
        }
        if (indexes[0] + 1 < args[0].length) {
            yield values;
        }
        else {
            return values;
        }
        //Increment starting from the last, until we get to the first.
        for (var i = args.length; i > 0; --i) {
            if (indexes[i]++ >= args[i].length) {
                indexes[i] = 0;
            }
            else {
                break;
            }
        }
    }
}

उदाहरण उपयोग:

for (let [target, child] of
    CombineEveryArgumentWithEveryArgument(targetsarray, childrenarray)) {

मैं मध्यस्थ चर बनाए बिना लक्ष्य और बच्चे के लिए टाइपिंग प्राप्त करने का कोई तरीका नहीं समझ सकता।

ऐसा कुछ अच्छा होगा?

function * generator<...T[]>(...args: T[]): [...T]

@Griffork सही अभ्यास, जब तक इस प्रस्ताव को लागू नहीं किया जाएगा, कार्यों के लिए कई अधिभार बनाना है
उदाहरण के लिए, वादा देखें। सभी प्रकार
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es2015.promise.d.ts#L41 -L113

मुझे यह वाक्यविन्यास बहुत भ्रमित लगता है:

function apply<...T,U>(ap: (...args:...T) => U, args: ...T): U {

यह मेरे लिए बहुत अधिक स्वाभाविक लगता है:

function apply<T, U>(ap: (...args: T) => U, args: T): U {

रनटाइम पर आराम पैरामीटर एक सरणी है, और हम इसे वर्तमान में टीएस में कर सकते हैं:

function apply<T, U>(ap: (...args: T[]) => U, args: T[]): U {

तो args एक सरणी होने के कारण T के प्रतिबंध को हटाना तर्कसंगत लगता है और इसके बजाय TS कंपाइलर को T लिए एक टपल प्रकार का अनुमान लगाने में सक्षम बनाता है, उदाहरण के लिए

function apply(ap: (...args: [number, number]) => number, args: [number, number]): number {

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

... अभी भी दो टपल प्रकारों को संयोजित करने के लिए मुझे समझ में आता है, जैसे [...T, ...U] ।

@felixfbecker
के लिए प्रस्ताव

function apply<...T,U>(ap: (...args:T) => U, ...args: T): U {

यह होगा कि T एक गतिशील रूप से बनाया गया टपल प्रकार है, इसलिए यदि आप फ़ंक्शन में string और int करते हैं, तो T [string, int] ।
यह विशेष रूप से दिलचस्प है यदि आप इस तरह के पैटर्न को गतिशील रूप से व्यक्त करना चाहते हैं:

function PickArguments<T>(a: T[]): [T];
function PickArguments<T, U>(a: T[], b: U[]): [T, U];
function PickArguments<T, U, V>(a: T[], b: U[], c: V[]): [T, U, V];
//More overloads for increasing numbers of parameters.

//usage:
var [a, b, c] = PickArguments(["first", "second", "third"], [1, 2, 3], [new Date()]);
var d = b + 1; //b and d are numbers.
var e = c.toDateString(); //c is a date (autocompletes and everything), e is a string.

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

आपका प्रस्ताव:

function apply<T, U>(ap: (...args: T) => U, args: T): U {

सभी मापदंडों को एक ही प्रकार के रूप में मानने के लिए बाध्य करता है, और उनके पास अधिक विशिष्ट प्रकार की जाँच नहीं हो सकती है। उदाहरण के लिए ऊपर दिए गए मेरे उदाहरण में, सभी लौटाए गए मान any ।

मुझे यह भी लगता है कि अतिरिक्त ... को पढ़ना बहुत कठिन है।
@felixfbecker विचार की तरह, मुझे ऐसा करने की आवश्यकता नहीं दिख रही है:

function apply<...T, U>(ap: (...args: ...T) => U, args: ...T): U {...}

apply<...T, पढ़ते समय सबसे पहले दिमाग में यह बात आती है कि यह एक स्प्रेड ऑपरेटर है, लेकिन वास्तव में यह फैलता बिल्कुल नहीं है।

@ ग्रिफोर्क , आपके उदाहरण में T अभी भी [string, int] ।
यही @felixfbecker का अर्थ है "टीएस कंपाइलर को टी के लिए एक टपल प्रकार का अनुमान लगाने के लिए सक्षम करने के बजाय", कम से कम जिस तरह से मैं इसे समझता हूं।

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

@ ग्रिफोर्क नहीं, मेरे दिमाग में यह args सरणी के लिए एक टुपल प्रकार का अनुमान लगाएगा , प्रत्येक पैरामीटर को टुपल में अपनी स्थिति से अपना प्रकार देगा। ...args: T[] उन सभी को एक ही प्रकार के होने के लिए मजबूर करेगा T , लेकिन ...args: T (जो वर्तमान में एक संकलन त्रुटि है) T लिए एक टपल प्रकार का अनुमान लगाएगा।

लागू करते समय सबसे पहली बात दिमाग में आती है<...T, यह है कि यह एक स्प्रेड ऑपरेटर है, लेकिन यह वास्तव में फैलता नहीं है।

@unional सहमत हैं, यही वह जगह है जहां से भ्रम उत्पन्न होता है।

@unional
मैंने इसे स्प्रेड ऑपरेटर के रूप में भी पढ़ा, मैंने इसे "इस प्रकार हर बार उपयोग किए जाने पर फैलाएं" के रूप में पढ़ा।
मेरे लिए, इसे पढ़कर

function apply<T, U>(ap: (...args: T) => U, args: T): U {

मैं T कुछ सरणी होने की अपेक्षा करता हूं (उदाहरण के लिए string[] )।

और इसे पढ़ना:

function apply<T, U>(ap: (...args: T[]) => U, args: T[]): U {

मैं उम्मीद करता हूं कि सभी तर्क T (जो एक प्रकार है, जैसे string ) के लिए असाइन करने योग्य हैं।

ऊपर प्रस्ताव की ओर बिंदु परोक्ष प्रकार के एक मनमाना राशि प्रतिनिधित्व करने में सक्षम जेनरिक करने से बचने के लिए किया गया था।

@felixfbecker
संपादित करें:
ओह ठीक। अभी भी यह मत सोचो कि यह सहज है।

मैं उम्मीद करता हूं कि टी कुछ सरणी हो (उदाहरण के लिए स्ट्रिंग [])।

एक टपल "कुछ सरणी" है, यह केवल एक निश्चित लंबाई और प्रत्येक तत्व के लिए विशिष्ट प्रकार के साथ एक सरणी है, उदाहरण के लिए [string, number] (बनाम (string | number)[] , जो अनबाउंड है और यह घोषित नहीं करता है कि किस तत्व में क्या है प्रकार)।

ठीक है तो आप क्या टाइप करते हैं यदि आप वास्तव में वह व्यवहार चाहते हैं?

सुनिश्चित नहीं है कि आप वास्तव में किस व्यवहार का जिक्र कर रहे हैं, लेकिन मुझे लगता है कि "सभी मानकों को एक ही प्रकार के होने के लिए मजबूर करें", जो ...args: T[] द्वारा पूरा किया जाएगा।

मैंने इसे स्प्रेड ऑपरेटर के रूप में भी पढ़ा, मैंने इसे "इस प्रकार हर बार उपयोग किए जाने पर फैलाएं" के रूप में पढ़ा।

इसलिए मुझे लगता है कि यह भ्रमित करने वाला है।
जब आप फैलते हैं, तो आप इसे करते हैं, आप कुछ ऐसा घोषित नहीं करेंगे जो "फैलाने योग्य" हो:

const a = { x: 1, y: 2 }
const b = { ...a }

// likewise
function appendString<T>(...args: T): [...T, string] {
  args.push('abc')
  return args
}

हां। यदि आप यह घोषित करना चाहते हैं कि एक सामान्य प्रकार के तर्क को "फैलाने योग्य" होने की आवश्यकता है (जो प्रति ES कल्पना का अर्थ है कि यह चलने योग्य होना चाहिए), तो हमारे पास पहले से ही टाइपस्क्रिप्ट में extends साथ व्यक्त करने का एक तरीका है:

function foo<T extends Iterable<any>>(spreadable: T): [...T, string] {
  return [...spreadable, 'abc']
}

const bar = foo([1, true])
// bar is [number, boolean, string]

बेशक, एक आराम पैरामीटर के मामले में यह ज्ञात है कि यह केवल Iterable नहीं है, बल्कि एक Array है।

जो, हम जो कह रहे हैं वह पहले ही प्रस्तावित किया जा चुका है: https://github.com/Microsoft/TypeScript/issues/5453#issuecomment -189703556

लेकिन एक सीटिंग में उपभोग करने के लिए बाकी बहुत लंबा है। मैं

अगर टपल कॉन्सटेनेशन उतर रहा है, तो हम चर्च नंबर लागू कर सकते हैं! हुर्रे!

type TupleSuc<T extends [...number]> = [...T, T['length']];
type TupleZero = [];  // as proposed, we need empty tuple
type TupleOne = TupleSuc<TupleZero>;
type Zero = TupleZero['length'];
type One = TupleOne['length'];

और अगर सशर्त प्रकार की पुनरावृत्ति काम कर रही है, तो हम वांछित लंबाई के साथ टपल बना सकते हैं:

type Tuple<N extends number, T = TupleZero> = T['length'] extends N ? T : Tuple<N, TupleSuc<T>>;
type TupleTen = Tuple<10>;
type Ten = TupleTen['length'];

मुझे नहीं लगता कि मैंने यह सब धागा पढ़ा है, लेकिन अगर सामान्य मानकों में ...T होने पर भ्रमित हो रहा है,
क्यों न वैल्यू-लेवल डिस्ट्रक्टिंग सिंटैक्स को आगे मिरर करने का प्रयास किया जाए, ताकि [...T] का उपयोग a . में किया जा सके
टाइप-लेवल तर्क स्थिति प्रकार को नष्ट कर देती है यदि यह एक प्रकार-स्तरीय टुपल है? इसकी भी आवश्यकता होगी
टुपल्स के साथ टाइपिंग रेस्ट पैराम की अनुमति देता है, जो कॉल साइट पर निम्नलिखित समकक्ष बना देगा
टाइपस्क्रिप्ट में:

const first = (a: number, b: string) => …;
const second = (...ab: [number, string]) => …;

first(12, "hello"); // ok
second(12, "hello"); // also ok

INB4 "लेकिन यह टाइप-निर्देशित उत्सर्जन है" - नहीं। यह उत्सर्जित नहीं करता है, first अभी भी दो हैं
अलग तर्क उत्सर्जित, second में अभी भी एक आराम तर्क होगा। केवल एक चीज जो बदलती है वह है
कि कॉल साइट पर, टाइपस्क्रिप्ट जाँच करेगा कि second के पैरामीटर, क्रम में, टपल से मेल खाते हैं
[number, string] ।

वैसे भी, मान लें कि हम [...Type] सिंटैक्स को स्वीकार करते हैं, तो हम apply इस प्रकार लिख सकते हैं:

function apply<
  [...ArgumentsT], // a type-level tuple of arguments
  ResultT
>(
  // the call site of `toApply` function will be used to infer values of `ArgumentsT`
  toApply:   (...arguments: ArgumentsT) => ResultT,
  arguments: ArgumentsT
) :
  ResultT
{
  // …
}

// NB: using my preferred formatting for complex type-level stuff; hope it's readable for you
// this is entirely equivalent to OP's notation version:
function apply<[...T], U>(ap: (...args: T) => U,  args: T): U {
  // …
}

// so at the call site of
const fn = (a: number, b: string, c: RegExp) => …;

// we have `ArgumentsT` equal to [number, string, RegExp]
apply(fn, [12, "hello" /s+/]); // ok, matches `ArgumentsT`
apply(fn, [12, /s+/]); // not ok, doesn't match `ArgumentsT`

[...Type] सिंटैक्स पूरी तरह से मूल्य-स्तर के विनाशकारी के रूप में व्यवहार करेगा, विभाजन के लिए अनुमति देगा
और आवश्यकतानुसार टाइप-लेवल टुपल्स में शामिल होना:

type SomeType  = [string, number, "constant"];
type OtherType = ["another-constant", number];

type First<[First, ..._]> = FirstT;
type Rest<[_, ...RestT]> = RestT;
type Concat<[...LeftT], [...RightT]> = [...LeftT, ...RightT];
type FirstTwo<[FirstT, SecondT, ..._]> = [FirstT, SecondT];

// has type `string`
const aString: First<SomeType> =
  "strrriiing";
// has type `[number, "constant"]
const numberAndConstant: Rest<SomeType> =
  [42, "constant"];
// has type `[string, number, "constant", "another-constant", number]`
const everything: Concat<SomeType, OtherType> =
  ["herpderp", 42, "constant", "another-constant", 1337];
// has type `[string, number]`
const firstTwo: FirstTwo<SomeType> =
  ["striiiing", 42];

इसका उपयोग करके curry फ़ंक्शन कैसे टाइप करें, इस पर एक उदाहरण:

type Curried<
  [...ArgumentsT]
  ResultT,
  ArgumentT      = First<ArgumentsT>,
  RestArgumentsT = Rest<ArgumentsT>
> =
  // just ye olde recursione, to build nested functions until we run out of arguments
  RestArgumentsT extends []
    ? (argument: ArgumentT) => ResultT
    : (argument: ArgumentT) => Curried<RestArgumentsT, ResultT>;

// NB. with more complex generic types I usually use generic defaults as a sort-of
// of type-level variable assignment; not at all required for this, just nicer to read IMO

function curry<
  [...ArgumentsT],
  ResultT
>(
  function: (...arguments: ArgumentsT) => ResultT
) :
  Curried<ArgumentsT, ResultT>
{
  // do the magic curry thing here
}

// or in the short indecipherable variable name style

function curry<[...T], U>(fn: (...args: T) => U): Curried<T, U>
{
  // …
}

// this should let you do this (using `fn` from before)
const justAddRegex = curry(fn)(123, "hello");

justAddRegex(/s+/); // ok, matches the arguments of `fn`
justAddRegex(123); // not ok, doesn't match the arguments of `fn`

मुझे लगता है कि यह कहने में भी मददगार होगा, कि कुछ प्रकार का तर्क एक प्रकार-स्तर का टपल है
किसी तरह की। तब मुद्दा यह होगा कि कैसे - 2.7 के बाद से विचार करना (मुझे लगता है?) टपल असाइनमेंटिबिलिटी लेता है
खाते में टपल लंबाई - _any प्रकार-स्तर tuple_ की अवधारणा को व्यक्त करने के लिए। पर शायद कुछ ऐसा
[...] काम कर सकता है? मेरे पास कोई मजबूत राय नहीं है, लेकिन यह अच्छा होगा यदि अवधारणा नाम योग्य हो।

// bikeshed me
type OnlyTuplesWelcome<ArgumentT extends [...]> = ArgumentT;

उस स्थिति में [...ArgsT] का उपरोक्त सिंटैक्स मूल रूप से ArgsT extends [...] लिए एक शॉर्टहैंड हो सकता है,
टाइप-लेवल डिस्ट्रक्टिंग का उपयोग करने से टाइप-लेवल टुपल होने के लिए टाइप पर एक बाधा आती है।

विचार?

@jaen :

(...ab: [number, string]) => …

हाँ, यह #4130 जैसा दिखता है। मैंने #1804 पर कुछ करने की कोशिश की, लेकिन मेरा दृष्टिकोण थोड़ा हैकी (सिंथेटिक नोड्स) था।

किसी भी टुपल को व्यक्त करने पर मैंने किसी को any[] & { 0: any } का उपयोग करते हुए देखा, जो मुझे लगता है कि खाली टुपल प्रकार fwiw तक काम करता है। मैंने व्यक्तिगत रूप से ज्यादा परेशान नहीं किया है, ज्यादातर सिर्फ any[] ।

RxJS को हर जगह इसकी जरूरत है। सबसे गंभीर रूप से Observable.prototype.pipe , जिसके लिए वर्तमान में हमारे पास कई अधिभार हैं, लेकिन मुझे हमेशा "बस एक और स्तर" जोड़ने के लिए कहा जा रहा है।

दूसरे @benlesh के लिए हम बड़े पैमाने पर

मैं ppipe का लेखक RXJS में पाइप फ़ंक्शन की तरह, इसकी आवश्यकता है। मुझे लगता है कि मुझे यहां एक पैटर्न दिखाई दे रहा है ^^

मैं runtypes का लेखक

https://github.com/pelotom/runtypes/blob/master/src/types/union.ts

मैं

मैं ramda के प्रकारों को फिर से pipe , लेंस और करी।
हमें कोडेजन की जरूरत थी क्योंकि करी सीधे ओवरलोड को बनाए रखने में असमर्थ थी। हमारा path प्रकार एक हजार लाइनों में फैला हुआ है, जिस बिंदु पर हमने पाया कि ओवरलोड प्रकार का प्रदर्शन भी समस्याग्रस्त हो गया था।

क्या बाकी तर्कों का अनुमान लगाने और उन्हें लागू करने की समस्या का समाधान हो गया है?

function example(head: string, ...tail: number[]): number[] {
  return [Number(head), ...tail]
}

function apply<T, U>(fn: (...args: T) => U, args: T): U {
  return fn.apply(null, args)
}

में टी के प्रकार के हैं apply(example, ['0', 1, 2, 3]) के रूप में मान लिया जाता है [string, number[]] , कॉल लागू करने के लिए एक त्रुटि उठाएंगे।

इसका मतलब है कि टी का प्रकार वास्तव में है

type T = [string, ...number[]]

या

type T =
  {0: string} &
  {[key: Exclude<number, 0>]: number} &
  Methods

वास्तव में एक अजीब जानवर है, लेकिन यह देखते हुए कि ({0: string} & Array<number>)[0] होगा
वर्तमान में string [1] का समाधान करता है, ऐसा लगता है कि बिना किसी बदलाव के एन्कोड करना संभव है
प्रकार प्रणाली के लिए।

[१] क्या यह एक बग है, क्या यह वास्तव में string | number होना चाहिए?

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

यह दुख की बात है कि ढाई साल बाद भी इसे किसी को नहीं सौंपा गया, यह एक बहुत ही महत्वपूर्ण विशेषता प्रतीत होती है :(

पीएस: मैंने दो दर्जन टिप्पणियां पढ़ी हैं, सीएमडी + एफ आदि की कोशिश की, यह जानकारी नहीं मिली।

@brunolemos नवीनतम डिज़ाइन मीटिंग में विविध प्रकारों का संदर्भ है
https://github.com/Microsoft/TypeScript/issues/23045
इस सुविधा को बनाने के लिए उन्हें पहले और अधिक आदिम और अवधारणाओं को पुनरावृत्त रूप से बनाने की आवश्यकता है, और जब पर्याप्त नींव होगी तो मुझे यकीन है कि वे इसे किसी भी मील के पत्थर में जोड़ देंगे

मैं एक काम कर रहे bind को लागू करने में कामयाब रहा

मै ऐसा नही कर सकता

type Last<T extends any[]> =
    T extends [infer P] ? P :
    ((...x: T) => any) extends ((x: any, ...xs: infer XS) => any) ? Last<XS> :

#14174 की बात है लेकिन एक रिश्ते के रूप में

@kgtkr संदर्भ के लिए @fightingcat के देखने चाल प्रत्यावर्तन की अनदेखी संकलक पाने के लिए।

धन्यवाद

type Last<T extends any[]> = {
    0: never,
    1: Head<T>,
    2: Last<Tail<T>>,
}[T extends [] ? 0 : T extends [any] ? 1 : 2];

हम्म, मेरा एक प्रश्न है। मेरे पास मिश्रणों को संभालने के लिए इस तरह का एक कोड है:

export const Mixed = <

    OP = {}, OS = {}, // base props and state
    AP = {}, AS = {}, // mixin A props and state
    BP = {}, BS = {}, // mixin B props and state
    // ...and other autogenerated stuff
>(

    // TODO: Find a way to write that as ...args with generics:
    a?: ComponentClass<AP, AS>,
    b?: ComponentClass<BP, BS>,
    // ...and other autogenerated stuff

) => {

    type P = OP & AP & BP;
    type S = OS & AS & BS;
    const mixins = [a, b];

    return class extends Component<P, S> {
        constructor(props: P) {
            super(props);
            mixins.map(mix => {
                if (mix) {
                    mix.prototype.constructor.call(this);
                    // some state magic...
                }
            });
        }
    };
};

मैं इसे निम्नलिखित की तरह उपयोग करता हूं:

class SomeComponent extends Mixed(MixinRedux, MixinRouter, MixinForm) {
     // do some stuff with mixed state
}

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

3.0 के साथ अब बाकी आर्ग को टपल घोषित करना संभव है

declare function foo(...args: [number, string, boolean]): void;

लेकिन क्या दिए गए फ़ंक्शन के टपल प्रकार के तर्क प्राप्त करना संभव है?

Arguments<foo> जैसा कुछ अच्छा होगा।

@whitecolor इसके बारे में कैसे?

type Arguments<F extends (...x: any[]) => any> =
  F extends (...x: infer A) => any ? A : never;

TS 3.0 के साथ हम इसे अभी कर सकते हैं

function compose<X extends any[], Y extends any[], Z extends any[]>(
  f: (...args: X) => Y,
  g: (...args: Y) => Z
): (...args: X) => Z {
  return function (...args) {
    const y = f(...args);
    return g(...y);
  };
}

लेकिन हमारे पास छोटी सी समस्या है, हमें ऐसे कार्यों की घोषणा करनी है जो एकल पैरा के लिए टुपल्स ईवेंट लौटाते हैं और किसी भी तरह से शून्य से निपटते हैं और हमें रिटर्न प्रकार घोषित करना होगा अन्यथा इसे सरणी के रूप में अनुमानित किया जाता है :)

https://www.typescriptlang.org/play/index.html#src =%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0Afunction%20foo0() %3A%20void%20%7B%0D%0A%20%0D%0A%7D%0D%0A%0D%0Afunction%20bar0()%3A%20void%20%7B%0D%0A%0D%0A%7D %0D%0A%0D%0Afunction%20foo1(a%3A%20string)%3A%20%5Bstring%5D%20%7B%0D%0A%20%20return%20%5Ba%5D%3B%0D%0A% 7D%0D%0A%0D%0Afunction%20bar1(a%3A%20string)% 3A% 20% 5Bstring% 5D% 20% 7B% 0D% 0A% 20% 20 रिटर्न% 20% 5Ba% 5D% 3B% 0D% 0A %7D%0D%0A%0D%0Afunction%20foo2(a1%3A%20string%2C%20a2%3A%20boolean)%3A%20%5Bstring%2C%20boolean%5D%20%7B%0D%0A%20% 20वापसी%20%5बीए1%2सी%20ए2%5डी%3बी%0डी%0ए%7डी%0डी%0ए%0डी%0एफंक्शन%20foo21(a1%3A%20string%2C%20a2%3A%20boolean)%3A%20%5Bstring % 5D% 20% 7B% 0D% 0A% 20% 20 वापसी% 20% 5Ba1% 5D% 3B% 0D% 0A% 7D% 0D% 0A% 0D% 0A% 0D% 0A फ़ंक्शन% 20bar2 (a1% 3A% 20string% 2C) % 20a2% 3A% 20boolean)% 3A% 20% 5Bstring% 2C% 20boolean% 5D% 20% 7B% 0D% 0A% 20% 20 वापसी% 20% 5Ba1% 2C% 20a2% 5D% 3B% 0D% 0A% 7D% 0D%0A%0D%0A%0D%0Afunction%20compose%3CX%20extend%20any%5B%5D%2C%20Y%20extend%20any%5B%5D%2C%20Z%20extend%20any%5B%5D%3E( %0D%0A%20%20f%3A%20(... args% 3A% 20X)% 20% 3D% 3E% 20Y% 2C% 0D% 0A% 20% 20g% 3A% 20 (... args% 3A% 20Y)% 20% 3D% 3E% 20Z% 0D% 0A )% 3A% 20 (... args% 3A% 20X)% 20% 3D% 3E% 20Z% 20% 7B% 0D% 0A% 20% 20 वापसी% 20 फ़ंक्शन% 20 (... args)% 20% 7B% 0डी%0ए%20%20%20%20const%20y%20%3D%20f(...args)%3B%0D%0A%20%20%20return%20g(...y)%3B% 0D%0A% 20% 20% 7D% 3B% 0D% 0A% 7D% 0D% 0A% 0D% 0A% 0D% 0A% 0D% 0A% 0D% 0Aconst% 20baz0% 20% 3D% 20compose(%0D%0A %20%20foo0%2C%0D%0A%20%20bar0%0D%0A)%3B%0D%0A%0D%0Aconst%20baz21%20%3D%20compose(%0D%0A%20%20foo21%2C%0D %0A%20%20bar1%0D%0A)%3B%0D%0Aconst%20baz2%20%3D%20compose(%0D%0A%20%20foo2%2C%0D%0A%20%20bar2%0D%0A)% 3B%0D%0A%0D%0A%0D%0Alert(baz2('a'%2C%20false))%0D%0Alert(baz21('a'%2C%20true))%0D%0Alert(baz0())

@maciejw
सशर्त प्रकारों का उपयोग करें:

function compose<X extends any[], Y extends any, Z extends any>(
  f: (...args: X) => Y,
  g: Y extends any[] ? (...args: Y) => Z : () => Z
): (...args: X) => Z {
    return function (...args) {
        const y = (f as any)(...args);
        return (g as any)(...y);
    } as any;
}

निश्चित रूप से, लेकिन यह उन as any साथ हैकी है :) मुझे लगता है कि यह अच्छा होगा यदि टाइप सिस्टम बिना हैक्स के इसका समर्थन करता है

ठीक है, फ़ंक्शन बॉडी में प्रकार कई चीजें हो सकते हैं, इसके बारे में वास्तव में बहुत कुछ नहीं किया जा सकता है - आप इसके बजाय (f as (...args: any[]) => Y) जैसा कुछ कर सकते हैं, लेकिन मुझे लगता है कि बिना किसी वास्तविक कारण के स्पष्टता कम हो जाती है

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

सामान्यीकरण जो मुझे अपने कोड को सरल बनाने की अनुमति देगा, साथ ही मनमानी एपीआई के लिए भी ऐसा ही करेगा, और आगे जाकर अन्य भाषा ग्राहकों के लिए भी स्वैगर परिभाषाएं उत्पन्न करेगा ... दूसरों के लिए उपयोगी हो सकता है! हाहाहा हालांकि जोर से सपने देखना

मैं पाइप टाइप करने में सफल रहा
https://github.com/kgtkr/typepark/blob/master/src/pipe.ts

@kgtkr : यह बहुत अच्छा लग रहा है! :)

पाइप प्रकार मेरे लिए टीएस खेल का मैदान दुर्घटनाग्रस्त हो जाता है (हालांकि अन्य ठीक काम करते हैं), मुझे लगता है कि इसे नवीनतम टीएस की आवश्यकता है?

टीएस कुछ रिकर्सन गहराई त्रुटियों को भी दिखाता है - ऐसा लगता है कि @isiahmeadows ने इसके लिए # 26980 खोला।

@ tycho01

पाइप प्रकार मेरे लिए टीएस खेल का मैदान दुर्घटनाग्रस्त हो जाता है (हालांकि अन्य ठीक काम करते हैं), मुझे लगता है कि इसे नवीनतम टीएस की आवश्यकता है?

यह मेरे लिए भी लटका हुआ है, और मुझे इसे तोड़ने के लिए एक त्रुटि फेंकने के लिए मजबूर करने के लिए devtools में हैक करना पड़ा।

टीएस कुछ रिकर्सन गहराई त्रुटियों को भी दिखाता है - ऐसा लगता है कि @isiahmeadows ने इसके लिए # 26980 खोला।

यह कुछ संबंधित है, लेकिन अलग है: सशर्त प्रकारों के साथ दो कारणों से बाधा उठाना:

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

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

दूसरे विचार पर, यह पाइप प्रकार (vs...: Params<T[0]>) => ReturnType<Last<T>> करने का वास्तव में जटिल तरीका लगता है। इससे परे कोई भी पुनरावृत्ति (मध्यवर्ती परम चेक से अलग) शायद इनपुट-निर्भर रिटर्न प्रकारों के साथ अधिक उपयोगी हो जाती है।

@ tycho01 यह इस तरह की चीजों को टाइप करने का प्रयास कर रहा है, जहां प्रकार मूल रूप से यह है:

   f1,     f2,   ...,   fm,     fn    -> composed
(a -> b, b -> c, ..., x -> y, y -> z) -> (a -> z)

आप पुनरावृति करने के लिए है मापदंडों को व्यक्तिगत रूप से इसे सही ढंग से टाइप करने के लिए, के बाद से बाद के मानकों वापसी मान 'मानकों पिछले मानकों पर निर्भर कर रहे हैं', और आप भी पहले पैरामीटर और अंत वापसी मान के लिए खाते में राशि (रों जो @kgtkr 'नहीं है) . # 26980 में मेरे "बेहतर" संस्करण ने इसके बजाय एक संचयक का उपयोग करने के लिए अनुकूलन किया, इसलिए मैं तर्कों को बहुत कम कर रहा था, लेकिन इसने इसे और भी सही बना दिया।

यदि आप #२६९८० में मेरा देखते हैं, तो यह थोड़ा स्पष्ट है कि इसे क्या करना चाहिए (कम संख्या का पीछा करना), और यह इस बात का एक हिस्सा है कि मैंने उस सुविधा अनुरोध को क्यों दायर किया।

@ tycho01 @kgtkr BTW, मैंने उस बग को एक सही PipeFunc स्निपेट के साथ अपडेट किया, जिसे सुविधा के लिए यहां कॉपी किया गया है:

type Last<L extends any[], D = never> = {
    0: D,
    1: L extends [infer H] ? H : never,
    2: ((...l: L) => any) extends ((h: any, ...t: infer T) => any) ? Last<T> : D,
}[L extends [] ? 0 : L extends [any] ? 1 : 2];

type Append<T extends any[], H> =
    ((h: H, ...t: T) => any) extends ((...l: infer L) => any) ? L : never;

type Reverse<L extends any[], R extends any[] = []> = {
    0: R,
    1: ((...l: L) => any) extends ((h: infer H, ...t: infer T) => any) ?
        Reverse<T, Append<R, H>> :
        never,
}[L extends [any, ...any[]] ? 1 : 0];

type Compose<L extends any[], V, R extends any[] = []> = {
    0: R,
    1: ((...l: L) => any) extends ((a: infer H, ...t: infer T) => any) ?
        Compose<T, H, Append<R, (x: V) => H>>
        : never,
}[L extends [any, ...any[]] ? 1 : 0];

export type PipeFunc<T extends any[], V> =
    (...f: Reverse<Compose<T, V>>) => ((x: V) => Last<T, V>);

यह खेल के मैदान में दुर्घटनाग्रस्त नहीं होता है, BTW। यह वास्तव में टाइप-चेक करता है और यह बहुत जल्दी करता है।

मैंने अभी तक संभावित _.flow या _.flowRight प्रकार पर इसका परीक्षण नहीं किया है, लेकिन इसे शुरुआती बिंदु के रूप में काम करना चाहिए।

@ tycho01
आवश्यक
टाइपस्क्रिप्ट@अगला
3.0.1/3.0.2 काम नहीं करता

इस सूत्र के लिए धन्यवाद, मैं बना यह

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

@Yuudaari मैं _.flow , Ramda का _.compose , आदि टाइप करना इस बग के लिए ड्राइविंग चीजों में से एक है, और एक सफल टाइपिंग इस मुद्दे को हल करने का हिस्सा है। वास्तव में, यह मूल समस्या विवरण में सूचीबद्ध कारणों में से एक है।

वास्तव में, इस बिंदु पर, मेरी राय है कि 99% समस्याएं जो आज वैरिएडिक्स के साथ मौजूद हैं, एर्गोनॉमिक्स के साथ हैं, कार्यक्षमता के साथ नहीं। हम टाइप कर सकते हैं Function.prototype.bind और Promise.all अनुक्रमित प्रकार, सशर्त प्रकार, और प्रत्यावर्तन का एक मिश्रण के साथ पूरी तरह (यदि आप एक बार-बार कर सकते हैं Append के लिए पुनरावृत्ति सूची Function.prototype.bind , और Promise.all एक साधारण पुनरावृत्ति होगी + Append ), बस ऐसा करना बहुत अजीब और बॉयलरप्लेटी है।

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

मुझे लगता है कि यहां घोषणाओं की प्रतीक्षा कर रहे लोगों ने बड़ी खबर को याद किया - यह अब संभव Concat<T, U> कार्य करता है जो बिल्कुल [...T, ...U] ।

Pipe उप-थ्रेड हमारे द्वारा यहां मांगी गई कार्यक्षमता को प्रदर्शित करने के बारे में है। यह आज इस सूत्र के बिंदु तक पहुँचने के बारे में है।

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

[यह] बस यह बहुत ही अजीब और बॉयलरप्लेटी है

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

उस समय शायद यह प्रस्ताव अधिकतर प्रदर्शन में सुधार कर सकता है?

सबसे पहले, मानचित्र ऑब्जेक्ट्स का उपयोग टाइप सिस्टम को रिकर्सन करने के इरादे से भी करने के लिए कर रहा है? यह मेरे लिए काफी हैकी लगता है। अगर मैं इस तरह की कार्यक्षमता का उपयोग करता हूं (मैं हूं, लेकिन यह अप्रासंगिक है), तो क्या यह बाद में टूटने के अधीन नहीं होगा?

दूसरे, इन वर्कअराउंड का उपयोग करना ठीक नहीं है... मित्रवत। यह बहुत पठनीय नहीं है (विशेषकर उन लोगों के लिए जिन्होंने इसे नहीं लिखा है), और इसके परिणामस्वरूप इसे बनाए रखना दयनीय लगता है।

मैं एक ऐसे प्रस्ताव पर वापस क्यों आना चाहता हूं जो समान सुविधाओं को एक इच्छित, पठनीय और रखरखाव योग्य तरीके से जोड़ता है, सिर्फ इसलिए कि उनके लिए एक समाधान है?

मुझे नहीं लगता कि इस समाधान के अस्तित्व के कारण इस प्रस्ताव को वाक्यात्मक चीनी माना जाता है, लेकिन अगर ऐसा होता भी, तो मैं इस गड़बड़ी के लिए वाक्य रचनात्मक चीनी क्यों नहीं चाहता?

@युदारी

संपादित करें: संदर्भ के लिए लिंक जोड़ें।

सबसे पहले, मानचित्र ऑब्जेक्ट्स का उपयोग टाइप सिस्टम को रिकर्सन करने के इरादे से भी करने के लिए कर रहा है? यह मेरे लिए काफी हैकी लगता है। अगर मैं इस तरह की कार्यक्षमता का उपयोग करता हूं (मैं हूं, लेकिन यह अप्रासंगिक है), तो क्या यह बाद में टूटने के अधीन नहीं होगा?

मेरे द्वारा हाल ही में दायर की गई बग पर एक नज़र डालें: #२६९८०। आप पैटर्न पर सवाल उठाने वाले अकेले नहीं हैं। यह यहां थोड़ा सा विषय है, लेकिन वहां झंकार करने के लिए स्वतंत्र महसूस करें।

ध्यान दें कि इसमें थोड़ा सा गणित शामिल है कि कैसे यह पता लगाया जाए कि क्या कुछ पुनरावर्ती समाप्त होता है (मुख्य कारणों में से एक यह पहली जगह में इतना बारीक क्यों है)।

दूसरे, इन वर्कअराउंड का उपयोग करना ठीक नहीं है... मित्रवत। यह बहुत पठनीय नहीं है (विशेषकर उन लोगों के लिए जिन्होंने इसे नहीं लिखा है), और इसके परिणामस्वरूप इसे बनाए रखना दयनीय लगता है।

मैं एक ऐसे प्रस्ताव पर वापस क्यों आना चाहता हूं जो समान सुविधाओं को एक इच्छित, पठनीय और रखरखाव योग्य तरीके से जोड़ता है, सिर्फ इसलिए कि उनके लिए एक समाधान है?

मुझे नहीं लगता कि इस समाधान के अस्तित्व के कारण इस प्रस्ताव को वाक्यात्मक चीनी माना जाता है, लेकिन अगर ऐसा होता भी, तो मैं इस गड़बड़ी के लिए वाक्य रचनात्मक चीनी क्यों नहीं चाहता?

प्रभावी रूप से Array.prototype.map के सामान्य मामले में टुपल्स को पुनरावृत्त करने का एक सरल तरीका मौजूद

मैं व्यक्तिगत रूप से इनके लिए वाक्य रचनात्मक चीनी पसंद करूंगा:

1. [...First, ...Second] माध्यम से दो सूचियों को जोड़ना।
2. [...Values, Item] माध्यम से मूल्यों को जोड़ना।
3. T extends [...any[], infer Last] माध्यम से अंतिम तत्व निकालना।
4. T extends [A, B, ...infer Tail] माध्यम से पूंछ निकालना।

इसे #26980 के साथ मिलाएं, और मैं उपरोक्त प्रकारों को इसमें बदल सकता हूं:

type Compose<L extends any[], V, R extends any[] = []> =
    L extends [infer H, ...infer T] ?
        Compose<T, H, [...R, (x: V) => H]> :
        R;

export type PipeFunc<T extends any[], V> =
    T extends [...any[], infer R] ?
        (...f: Compose<T, V>) => ((x: V) => R) :
        () => (x: V) => V;

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

सबसे पहले, मानचित्र ऑब्जेक्ट्स का उपयोग टाइप सिस्टम को रिकर्सन करने के इरादे से भी करने के लिए कर रहा है? यह मेरे लिए काफी हैकी लगता है। अगर मैं इस तरह की कार्यक्षमता का उपयोग करता हूं (मैं हूं, लेकिन यह अप्रासंगिक है), तो क्या यह बाद में टूटने के अधीन नहीं होगा?

मुझे लगता है कि आधिकारिक शब्द "ऐसा मत करो" जैसा कुछ है। @ahejlsberg ने कहा :

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

मत करो!

️

@jcalz तो # 26980 के अस्तित्व में आने का और भी कारण?

जब मैंने इस साल के एक ब्रेक के बाद TS का उपयोग करना शुरू किया, तो मेरा झुकाव _just that_! लिखने का था! ( ...T ) इस उम्मीद में कि यह वैरिएडिक टाइपवार टुपल्स के लिए सिंटैक्स होगा। खैर, आशा है कि यह अंदर आ जाएगा :)

[...T, ...U] लिए बस एक नया उपयोग मिला: HTML बिल्डरों को सही ढंग से टाइप करना। एक ठोस उदाहरण के लिए, <video> के बच्चों का निम्नलिखित होना आवश्यक है:

• यदि तत्व में src विशेषता है:
  
  
  
  • शून्य या अधिक <track> तत्व
  
  
• यदि तत्व में src विशेषता नहीं है:
  
  
  
  • शून्य या अधिक <source> तत्व
  
  
• माता-पिता के सामग्री मॉडल के अनुसार शून्य या अधिक तत्व, सिवाय audio या video वंशज तत्व की अनुमति नहीं है।

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

type VideoChildren<ParentModel extends string[]> = [
    ...Array<"track">, // Not possible
    ...{[I in keyof ParentModel]: P[I] extends "audio" | "video" ? never : P[I]},
]

3.5 साल :/

उदाहरण:

type DrawOp<...T> = (G: CanvasRenderingContext2D, frame: Bounds, ...args: any[]) => void;
const drawOps: DrawOp<...any>[] = [];

function addDrawOp<...T>(fn: DrawOp<...T>, ...args: T) {
    drawOps.push(fn);
}

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

  function $findOne(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    cb: Cb<TSchema>,
  ): void;
  function $findOne<T extends keyof TSchema>(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    projection: Projection<T>,
    cb: Cb<Pick<TSchema, T>>,
  ): void;
  function $findOne(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    projection: undefined,
    cb: Cb<TSchema>,
  ): void;
  function $findOne<T extends keyof TSchema>(
    ctx: ICtx,
    filter: mongodb.FilterQuery<TSchema>,
    projection: Projection<T> | Cb<TSchema> | undefined,
    cb?: Cb<Pick<TSchema, T>>,
  ): void {

  promisify($findOne) // this can't infer types correctly

वर्तमान में यह बिल्कुल भी काम नहीं करता है और केवल promisify को (ctx: ICtx, filter: FilterQuery<TSchema>) => Promise<TSchema[]> रूप में टाइप करता है जो इन हस्ताक्षरों से जानकारी खो रहा है।

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

यह इस तथ्य से बढ़ा है कि बाकी पैरामीटर केवल अंतिम पैरामीटर हो सकते हैं (यानी (cb, ...args) मान्य है लेकिन (...args, cb) , इसलिए भले ही हस्ताक्षर आंतरिक रूप से एक संघ प्रकार है, आप वास्तव में नहीं कर सकते चीजों को सही ढंग से फैलाएं - उदाहरण के लिए यह काफी सरल होगा यदि cb हमेशा function promisify<T, V extends any[]>(fn: (cb: (err: Error | null, res?: T) => void, ...args: V)): (...args: V) => T रूप में वादा करने का पहला तर्क था और आप कम से कम समान वापसी प्रतिक्रिया के साथ हस्ताक्षर के लिए संघ प्रकार प्राप्त कर सकते थे, लेकिन क्योंकि यह अंतिम पैरामीटर है क्योंकि यहां बहुत कुछ नहीं किया जा सकता है

@Qix- आपका परिदृश्य #24897 द्वारा सक्षम किया गया है। टीएस 3.0 में लागू किया गया था।

@ahejlsberg ऊफ! बहुत बढ़िया, धन्यवाद ️

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

और अब उन्हें ts-toolbelt के साथ भेज दिया गया है।

हालांकि, यह प्रस्ताव सामान्य टपल जोड़तोड़ को बहुत आसान बनाने के लिए एक अच्छी वाक्यात्मक चीनी है।

क्या आपके पास यह पहले से ही माध्यम.कॉम पर है? यूआरएल?

माध्यम पर मूल लेख है लेकिन इसमें बोनस शामिल नहीं है, यह रेपो में है। यह यह भी बताता है कि कैसे मैंने रचना, पाइप और करी प्राप्त करने के लिए सभी छोटे उपकरण बनाए: मुस्कान:

@ pirix-gh लेकिन यह इस प्रस्ताव में वैरिएडिक जेनरिक नहीं है

declare function m<...T>(): T

m<number, string>() // [number, string]

@goodmind हाँ, ऐसा नहीं है, यह अधिक अनुकरणीय है। तो आप इस तरह ... का अनुकरण कर सकते हैं:

declare function m<T extends any[], U extends any[]>(): Concat<T, U>

m<[number, string], [object, any]>() // [number, string, object, any]

वैसा ही है जैसा कि:

declare function m<...T, ...U>(): [...T, ...U]

m<number, string, object, any>() // [number, string, object, any]

इस बीच, इस प्रस्ताव की प्रतीक्षा करते हुए :hourglass_flowing_sand:

@ pirix-gh क्या आप कृपया रैपिंग फंक्शन में मदद कर सकते हैं जैसे

type fn = <T>(arg: () => T) => T
let test1: fn
let res1 = test1(() => true) // boolean

type fnWrap = (...arg: Parameters<fn>) => ReturnType<fn>
let test2: fnWrap
let res2 = test2(() => true) // {}

मैं रचना दृष्टिकोण का उपयोग करने की कोशिश कर रहा था लेकिन असफल रहा, क्या आप कृपया उचित तरीके से सुझाव दे सकते हैं?

ऐसा इसलिए होता है क्योंकि जब आप जेनरिक पर निर्भर fn के पैरामीटर/रिटर्न निकालते हैं, तो TS उन्हें उनके निकटतम प्रकार का अनुमान लगाता है (इस मामले में T होगा any )। तो फिलहाल इसके लिए कोई रास्ता नहीं है। हमारी सबसे अच्छी उम्मीद है कि इस प्रस्ताव को https://github.com/Microsoft/TypeScript/pull/30215 के साथ संयोजित करने के लिए प्रतीक्षा

या, हो सकता है कि हम जेनरिक को इस तरह से संरक्षित/स्थानांतरित करने का कोई तरीका ढूंढ सकें कि हम कर सकें:

declare function ideal<...T>(a: T[0], b: T[1], c: T[2]): T

ideal('a', 1, {}) // T = ['a', 1, {}]

इस तरह, हम इसके टुकड़ों से fn पुनर्निर्माण करेंगे। आज गायब हिस्सा सामान्य हिस्सा है जैसे @goodmind ने बताया।

@ pirix-gh अगर मुझे गलत नहीं लगता है, तो आप इसे हासिल करने के लिए ऐसा कर सकते हैं जो आपके पास है:

declare function MyFunction<A, B, C, Args extends [A, B, C]>(...[a, b, c]: Args): Args

const a = MyFunction(1, 'hello', true);
// typeof a = [number, string, boolean]

@ClickerMonkey बिल्कुल नहीं, क्योंकि मैंने जो प्रस्तावित किया वह असीमित मात्रा में तर्कों के लिए काम करता है। लेकिन हो सकता है कि हम यह भी कर सकें, जो आपने प्रस्तावित किया है (मैंने इसे प्रस्ताव में नहीं देखा है):

declare function MyFunction<A, B, C, ...Args>(...[a, b, c]: Args): Args

const a = MyFunction(1, 'hello', true);
// typeof a = [number, string, boolean]

@pirix-gh आपके उदाहरण में A , B और C प्रकार के तर्क अप्रयुक्त हैं।

-declare function MyFunction<A, B, C, ...Args>(...[a, b, c]: Args): Args
+declare function MyFunction<...Args>(...[a, b, c]: Args): Args

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

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

@goodmind हाँ, ऐसा नहीं है, यह अधिक अनुकरणीय है। तो आप इस तरह ... का अनुकरण कर सकते हैं:

declare function m<T extends any[], U extends any[]>(): Concat<T, U>

m<[number, string], [object, any]>() // [number, string, object, any]

वैसा ही है जैसा कि:

declare function m<...T, ...U>(): [...T, ...U]

m<number, string, object, any>() // [number, string, object, any]

इसी बीच इस प्रस्ताव का इंतजार करते हुए

आपको Concat<> कहां से मिला?

संपादित करें: स्रोत कोड कभी नहीं मिला।

@ pirix-gh तो मैंने आपके सुझावों के साथ ऐसा करने की कोशिश की लेकिन इसे समझ नहीं पाया।

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

Class Test {
  constructor(x: number, y: string) {}
}
let ExtendedClass = extendCtor<[number, string], [number]>(Test);

let instance = new ExtendedClass(1, '22', 2);

अद्यतन: कोई बात नहीं कि सीटीआर फ़ंक्शन में स्प्रेड का उपयोग करके भी काम किया।

ये रहा समाधान का लिंक

एकमात्र समस्या यह है कि लगभग हर बार TS
और यही टाइपस्क्रिप्ट कहता है Type instantiation is excessively deep and possibly infinite.ts(2589)

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

// ...
type CtorArgs<T, X> = T extends (new (...args: infer U) => any) ? [...U, X] : never;
// To be used as CtorArgs<typeof Test, string>
// ...
let instance = new MyClass1('22', 2, 'check');

विरोध के रूप में:

let MyClass1 = extendClass<typeof Test, string>(Test);

let instance = new MyClass1('check', '22', 2);

अंतिम समाधान से लिंक करें ।

अगर मैं सही ढंग से समझता हूं तो Object.assign को विभिन्न तर्कों का पूरी तरह से समर्थन करने के लिए निम्नलिखित की तरह कुछ घोषित किया जा सकता है।

type Assign<T, U extends any[]> = {
  0: T;
  1: ((...t: U) => any) extends ((head: infer Head, ...tail: infer Tail) => any)
    ? Assign<Omit<T, keyof Head> & Head, Tail>
    : never;
}[U['length'] extends 0 ? 0 : 1]

interface ObjectConstructor {
  assign<T, U extends any[]>(target: T, ...source: U): Assign<T, U>
}

क्या टाइपस्क्रिप्ट के lib.d.ts में इसे अलग तरीके से घोषित करने का कोई कारण है?

यह पुनरावर्ती सशर्त प्रकारों का उपयोग नहीं कर रहा है क्योंकि वे समर्थित नहीं हैं (उस पर चर्चा के लिए # 26980 देखें, या यह टिप्पणी हमें ऐसा न करने के लिए कह रही है)। यदि कोई वर्तमान चौराहे के रिटर्न प्रकारों का उपयोग करने को तैयार है तो #28323 है।

@jcalz मैंने एक भारी परीक्षण बनाया जो Minus प्रकार की कार्रवाई दिखाता है। यह 4 सेकंड से भी कम समय में Minus 216000 बार प्रदर्शन करता है। इससे पता चलता है कि TS पुनरावर्ती प्रकारों को बहुत अच्छी तरह से संभाल सकता है। लेकिन यह काफी हाल का है।

क्यों? यह एंडर्स के लिए धन्यवाद है: टाडा: (https://github.com/microsoft/TypeScript/pull/30769)। उन्होंने मुझे सशर्त प्रकारों से अनुक्रमित स्थितियों (एक स्विच की तरह) पर स्विच करने की अनुमति दी। और वास्तव में, इसने ts-toolbelt के लिए x6 द्वारा प्रदर्शन में सुधार किया। बहुत-बहुत, उनका बहुत-बहुत धन्यवाद।

तो तकनीकी रूप से, हम ts- toolbelt के साथ

import {O, I, T} from 'ts-toolbelt'

// It works with the same principles `Minus` uses
type Assign<O extends object, Os extends object[], I extends I.Iteration = I.IterationOf<'0'>> = {
    0: Assign<O.Merge<Os[I.Pos<I>], O>, Os, I.Next<I>>
    1: O
}[
    I.Pos<I> extends T.Length<Os>  
    ? 1
    : 0
]

type test0 = Assign<{i: number}, [
    {a: '1', b: '0'},
    {a: '2'},
    {a: '3', c: '4'},
]>

लिब Iteration साथ रिकर्सन को भी सुरक्षित बनाता है जो टाइपस्क्रिप्ट से किसी भी अतिप्रवाह को रोक देगा। दूसरे शब्दों में, यदि I 40 से अधिक हो जाता है तो यह ओवरफ्लो हो जाता है और Pos<I> बराबर होता है number । इस प्रकार रिकर्सन को सुरक्षित रूप से रोकना।

एक समान पुनरावर्ती प्रकार जो मैंने लिखा था ( Curry ) रामदा के साथ भेज दिया गया है , और ऐसा लगता है कि यह अच्छा कर रहा है।

वैसे, मैंने परियोजना के पृष्ठ पर आपकी सभी अच्छी सलाह के लिए आपको (@jcalz) धन्यवाद दिया।

मुझे यकीन नहीं है कि #5453 इस चर्चा के लिए सबसे अच्छी जगह है... क्या हमें इस बारे में #26980 में बात करनी चाहिए या कोई और प्रामाणिक स्थान है? किसी भी मामले में मैं इस जो संभवतः टाइपप्रति के बाद के रिलीज पर फटना नहीं होगा करने के लिए एक अधिकारी और समर्थित तरीका है अच्छा लगेगा। कुछ ऐसा है जो उनके बेसलाइन परीक्षणों में शामिल है ताकि अगर यह टूट जाए तो वे इसे ठीक कर देंगे। यहां तक ​​​​कि अगर प्रदर्शन को अच्छा होने के लिए परीक्षण किया जाता है, तो मैं किसी भी उत्पादन वातावरण में @ahejlsberg जैसे किसी आधिकारिक शब्द के बिना ऐसा करने से सावधान रहूंगा।

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

मुझे लगता है कि हमारे पास आंतरिक रूप से उपयोग किए जाने वाले कुछ बहुत करीब है

@weswigham मुझे घने होने के लिए क्षमा करें, लेकिन क्या आप मुझे दिखा सकते हैं कि हाइलाइट किया गया प्रकार रिकर्सिव कैसे है? मैं जिस चीज को लेकर चिंतित हूं वह है फॉर्म

type Foo<T> = { a: Foo<Bar<T>>, b: Baz }[Qux<T> extends Quux ? "a" : "b" ]

या मेरे द्वारा देखे गए किसी भी प्रकार के। अगर मुझे कुछ याद आ रहा है और इसे किसी प्रकार की हरी बत्ती दी गई है, तो कृपया कोई मुझे बताएं (और मुझे इसका उपयोग करना सिखाएं!)

ओह, निष्पक्ष - यह उस संबंध में अलग है, हाँ। मैं सिर्फ "प्रकार का चयन करने के लिए तुरंत अनुक्रमित वस्तु" पैटर्न कहता हूं और महसूस किया कि हमारे पास _that_ था।

मेरा एक सवाल है।

यहां प्रस्तावित सामग्री का कितना हिस्सा अभी भी प्रासंगिक है? यह मुद्दा 4 साल पहले खोला गया था और मुझे लगता है कि तब से सामान का एक गुच्छा बदल गया है।

मेरी टिप्पणी यहाँ से,
https://github.com/microsoft/TypeScript/issues/33778#issuecomment -537877613

मैंने कहा,

टीएल; डीआर, टपल प्रकार, बाकी तर्क, मैप किए गए सरणी प्रकार, गैर-बाकी तर्क के लिए टपल-अनुमान, पुनरावर्ती प्रकार उपनाम = परिवर्तनीय प्रकार तर्क समर्थन की कोई वास्तविक आवश्यकता नहीं है

लेकिन मैं यह देखने के लिए उत्सुक हूं कि क्या किसी के पास उपयोग का मामला है जिसे मौजूदा टूल द्वारा सक्षम नहीं किया जा सकता है

जब तक हमें Concat<T extends any[], U extends any[]> आधिकारिक रूप से धन्य संस्करण नहीं मिल जाता, तब तक यह प्रासंगिक है। मुझे नहीं लगता कि आगामी पुनरावर्ती प्रकार संदर्भ सुविधा हमें यह देती है, लेकिन मुझे (आधिकारिक रूप से) अन्यथा बताए जाने में खुशी होगी।

क्या हमारे पास पहले से ही Concat<> कार्यान्वयन नहीं है?

या यहाँ मुख्य वाक्यांश "आधिकारिक तौर पर धन्य" है?

क्योंकि मेरा दावा यह है कि आप मूल रूप से सब कुछ (या लगभग सब कुछ?) कर सकते हैं जो आप इस समय चाहते हैं, भले ही वह "आधिकारिक तौर पर धन्य" न हो।

लेकिन मुझे लगता है कि "आधिकारिक तौर पर धन्य" को हमेशा प्राथमिकता दी जानी चाहिए ... अच्छी बात। मैं भी उन पुनरावर्ती प्रकार के उपनामों का उपयोग करके (ab) का उपयोग कर रहा हूं

मैं आम तौर पर एक वास्तविक, सुरुचिपूर्ण वाक्यविन्यास पसंद करूंगा ताकि हर बार जब मैं ऐसा कुछ करूं तो मुझे अपने (अक्सर जूनियर) टीम के साथियों को यह समझाने की ज़रूरत नहीं है कि भ्रमित रूप से निर्दिष्ट प्रकारों के लिए क्या हो रहा है जो यथास्थिति के दुरुपयोग की आवश्यकता है। यह भ्रम मेरी org.

इस पर बड़ा !

यह सुविधा SO महत्वपूर्ण है।

@AnyhowStep

क्योंकि मेरा दावा है कि आप मूल रूप से सब कुछ (या लगभग सब कुछ?) कर सकते हैं जो आप इस समय चाहते हैं

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

@ मैथ्यू-डीन पूरी तरह से सच नहीं है। यहां एक उदाहरण दिया गया है जिसे आप कुछ हद तक हासिल कर सकते हैं।

जैसा कि मैं समझता हूं कि TS अधिक से अधिक वैनिला JS प्रोग्राम टाइप करना चाहता है। यहाँ एक पहेली है:

const f = <T extends any[]>(...args: T): T => args;
const g = <T extends any[]>(...a: T): WhatExactly<T> => {
    return f(3, ...a, 4, ...a, 5);
}
g(1, 2);

मुझे उम्मीद है कि इस प्रकार का प्रकार [number, ...T, number, ...T, number] से अधिक जटिल नहीं होगा। अगर हमें कुछ अजीब कोड की 20 लाइनें लिखनी हैं जो बग का दुरुपयोग करती हैं तो अंतिम पंक्ति में उचित रिटर्न प्रकार की जांच करें, यह समस्या हल नहीं होती है।

@ polkovnikov-ph वर्तमान में इस प्रकार का अनुमान लगाया गया है: [number, ...any[]] , जो अनुपयोगी है।

साथ ही मैं यह भी नोटिस करना चाहूंगा कि हमें ग्रीनस्पन के दसवें नियम का 15 वर्षों तक सम्मान करने की आवश्यकता नहीं है जैसे कि C++ ने किया था, क्योंकि C++ पहले ही हमारे लिए सभी Head<> s और Cons<> से गुजर चुका है, और कुछ बहुत ही आसान और स्वच्छ विविध टेम्पलेट सिंटैक्स तैयार किया। हम डेवलपर समय (सैकड़ों वर्ष) बचा सकते हैं और वहां से केवल सर्वोत्तम भागों को ले सकते हैं।

उदाहरण के लिए, भिन्न प्रकार के C++ में भिन्न extends any[] प्रकार के विपरीत, जहां प्रकार अपेक्षित है, वहां भिन्न प्रकार के चर का उपयोग नहीं कर सकते। यह सी ++ को इलिप्सिस ऑपरेटर में संलग्न कुछ अभिव्यक्ति के अंदर विविध प्रकार चर का उल्लेख करके टुपल्स पर मैप/ज़िप करने की अनुमति देता है। यह मैप किए गए ऑब्जेक्ट प्रकारों का एक टपल विकल्प है।

type Somethify<...T> = [...Smth<T>]
type Test1 = Somethify<[1, 2]> // [Smth<1>, Smth<2>]

type Zip<...T, ...U> = [...[T, U]]
type Test2 = Zip<[1, 2], [3, 4]> // [[1, 3], [2, 4]]

type Flatten<...T extends any[]> = [......T]
type Test3 = Flatten<[[1, 2], [3, 4]]> // [1, 2, 3, 4]

कृपया उल्लेख करें कि extends any[] बजाय प्रस्तावित इलिप्सिस सिंटैक्स का उपयोग उदाहरण में न केवल सौंदर्य कारणों से किया जाता है, बल्कि इसलिए कि

type A<T> = any[]
type B<T extends any[]> = [...A<T>]
type C = B<[1, 2]>

पहले से ही एक वैध TS कार्यक्रम है। C अंत में any[] बजाय [any[], any[]] समाप्त होता है जो मैप किए गए विविध प्रकार उत्पन्न करेगा।

@DanielRosenwasser मैं आपको इस तरह पिंग करने के लिए क्षमा चाहता हूं, लेकिन मैं इस मुद्दे को फिर से शुरू करना चाहता था ताकि यह मौका बढ़े कि इसे कुछ प्यार मिले। विविध प्रकार सुपर सहायक होंगे, हालांकि मुझे एहसास है कि उन्हें लागू करना एक बड़ा काम है!

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

type SharedValues = [S1, S2, S3];
type TupleOfSpecificKind = [V1, ...SharedValues, V2];

@sethfowler यदि आपके पास कुछ उदाहरण हैं जो आप व्यक्त करना चाहते हैं, तो यह हमेशा हमारे लिए सहायक होता है। अन्यथा आपको https://github.com/microsoft/TypeScript/issues/26113 . में रुचि हो सकती है

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

type OpLineSegment = [
  StrokeColor,
  FillColor,
  number,  // thickness
  number, number, number,  // X0, Y0, Z0
  number, number, number  // X1, Y1, Z1
];
type OpCircle = [
  StrokeColor,
  FillColor,
  number, number, number,  // X, Y, Z of center
  number // radius
];
type OpPolygon = (StrokeColor | FillColor | number)[];  // [StrokeColor, FillColor, repeated X, Y, Z]]
type OpFan = (StrokeColor | FillColor | number)[];  // StrokeColor, FillColor, repeated X, Y, Z up to 10x

हम इन प्रकारों को और अधिक इस तरह व्यक्त करने में सक्षम होना चाहते हैं:

type Colors = [StrokeColor, FillColor];
type Vertex3D = [number, number, number];

type OpLineSegment = [...Colors, number /* thickness */, ...Vertex3D, ...Vertex3D];
type OpCircle = [...Colors, ...Vertex3D, number /* radius */];
type OpPolygon = [...Colors, ...Repeated<...Vertex3D>];
type OpFan = [...Colors, ...RepeatedUpToTimes<10, ...Vertex3D>];

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

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

const colors: Colors = getColors();
const center: Vertex3D = getCenter();

// Doesn't work! Produces a homogenous array.
const circle1: OpCircle = [...colors, ...center, radius];

// Doesn't work; can't write this function today.
const circle2: OpCircle = concat(colors, center, radius);

// We need to do this today; it's quite painful with more complex tuple types.
const circle3: OpCircle = [colors[0], colors[1], center[0], center[1], center[2], radius];

उम्मीद है कि ये उदाहरण मददगार होंगे!

आप Concat<> प्रकार आसानी से लिख सकते हैं, और Concat3<> का उपयोग करके Concat<> ।

फिर,

type OpCircle = Concat3<Colors, Vertex3D, [number] /* radius */>;

ऊपर से, आप 2,3,4,5,6, आदि के लिए ओवरलोड के साथ एक कॉन्सैट फ़ंक्शन लिख सकते हैं। तर्कों की संख्या।

Concat<> impl लिखना भी संभव है जो टुपल्स का एक टपल लेता है और टुपल्स को जोड़ता है। एक var-arg Concat<> प्रकार।

यह कोई ऐसी चीज नहीं है जो आज नहीं की जा सकती। यह किया जा सकता है, भले ही इसके लिए आपको एक पुनरावर्ती प्रकार, और सहायक फ़ंक्शन लिखने की आवश्यकता हो।

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

हो सकता है कि टाइप लिखने वाले लोग इसे ऑप्टिमाइज़ करने के लिए पर्याप्त नहीं कर रहे हों?

मैं पुरानी बातचीत में स्पैम या ड्रैग नहीं करना चाहता, जो इस धागे में अधिक मूल्य नहीं जोड़ेंगे, लेकिन मुझे कुछ बिंदु पर याद है कि जावास्क्रिप्ट में पुनरावर्ती सशर्त प्रकारों की गणना महंगी है (मैंने इसे यहां इस धागे में पाया)

उस ने कहा (मुझे पता है कि यह पागल लग सकता है,) हो सकता है कि टीएस को किसी अन्य भाषा में फिर से लिखने का समय हो ताकि टाइप सिस्टम को बढ़ावा मिल सके क्योंकि टीएस पहले से ही इतना बड़ा हो गया है कि बेहतर के लिए पूछना उचित है।

आप Concat<> प्रकार आसानी से लिख सकते हैं, और Concat3<> का उपयोग करके Concat<> ।

क्या आप कृपया उस Concat<> प्रकार के लिए कार्यान्वयन प्रदान कर सकते हैं जिसका आप वर्णन कर रहे हैं? Cons<> लिखना आसान है, लेकिन Concat<> इतना आसान नहीं है (मेरे लिए) और मुझे यह देखना अच्छा लगेगा कि आप क्या कल्पना कर रहे हैं।

Concat3<> , Concat4<> , आदि के संबंध में, आशा है कि लंबी अवधि में हमें इस तरह के दर्जनों प्रकार लिखने की आवश्यकता नहीं होगी, क्योंकि हमारे पास विविध प्रकार होंगे। यदि आज उनका एक अच्छा कार्यान्वयन संभव है, तो यह एक उचित स्टॉपगैप उपाय होगा।

दो टुपल्स के नियमित संयोजन के लिए,
https://github.com/AnyhowStep/ts-trampoline-test (बहुत बड़े टुपल्स को कॉनकैट करने के लिए ट्रैम्पोलिन का उपयोग करता है, जिसकी अधिकांश लोगों को आवश्यकता नहीं होगी)

Concat3 सिर्फ Concat , सी>

VarArgConcat होगा,
VarArgConcat<TuplesT extends readonly (readonly unknown[])[], ResultT extends readonly unknown[] = []>

जबकि टपल खाली नहीं है, VargArgConcat<PopFront<TuplesT>, Concat<ResultT, TuplesT[0]>>

यदि TuplesT खाली है, तो ResultT लौटाएं

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

मैं जिस रेपो से जुड़ा हूं वह Reverse<> को लागू करने के लिए Concat<> । मैंने जिस अन्य प्रोजेक्ट पर काम कर रहा हूं, उसके कोड को कॉपी-पेस्ट किया।

मैं सहमत हूं कि यह एक जबरदस्त उपयोगी सुविधा होगी।

मान लें कि हमारे पास एक प्रकार है T :

type T = {
  tags: ["a", "b", "c"];
};

और हम T["tags"] टपल में एक अतिरिक्त टैग "d" साथ एक नया प्रकार बनाना चाहते हैं। उपयोगकर्ता शुरू में इस उपयोगिता ( WithTag<NewTag, ApplyTo> ) का प्रयास कर सकते हैं और इस प्रकार बना सकते हैं:

type WithTag<
  Tag extends string,
  Target extends {tags: string[]}
> = Target & {
  tags: [Tag, ...Target["tags"]];
};

इसका प्रयास वर्तमान में A rest element type must be an array type त्रुटि फेंकता है। उपयोगकर्ता सोच सकते हैं कि string[] लिए Array<string> अदला-बदली करने से फर्क पड़ता है, लेकिन ऐसा नहीं है। न ही एक शर्त + never का उपयोग करता है:

type WithTag<
  Tag extends string,
  Target extends {tags: string[]}
> = Target & {
- tags: [Tag, ...Target["tags"]];
+ tags: Target["tags"] extends string[] ? [Tag, ...Target["tags"]] : never;
};

खेल का मैदान लिंक: https://www.typescriptlang.org/play?#code/C4TwDgpgBA6glsAFgFQIYHMA8AoKU3pQQAewEAdgCYDOU1wATnOegDS76oPoTBGkUaUAN7AM1AFx1GzdAG0AugF9sAPigBeTt15QAZCI5j0kqHIKsoAOhtodwOQCJj1RwoUBubEq -ZQkKABJTUM8FyknVEdLRwAjaKhHAGM3Lx9sP3BoZBD4JAJMR0oEwNVfAHoAKkrcSqgAUWJIJLJKKAADZHaoYAB7KFjoXoAzHsRoYd6AGynegHdZHqyrWqhV4VWe8QjHKJj4mJSY4s9VlShK8qA

संबंधित मुद्दे: :

• https://github.com/microsoft/TypeScript/issues/33783
• https://github.com/microsoft/TypeScript/issues/16746
• https://github.com/Microsoft/TypeScript/issues/26058

दुर्भाग्य से, यह रणनीति बाकी मापदंडों के लिए काम नहीं करती है। ये सिर्फ सरणियों में बदल जाते हैं:

function i(a: number, b?: string, ...c: boolean[]): number {
}
let curried = curry(i, 12);
curried('foo', [true, false]);
curried([true, false]);

यहाँ, करी: ...([string, boolean[]] | [boolean[]]) => number ।
मुझे लगता है कि इसका समर्थन किया जा सकता है यदि टुपल रेस्ट पैरामीटर वाले कार्यों के लिए एक विशेष मामला था, जहां टुपल का अंतिम तत्व एक सरणी है।
उस स्थिति में फ़ंक्शन कॉल सरणी से मेल खाने के लिए सही प्रकार के अतिरिक्त तर्कों की अनुमति देगा।
हालांकि, यह सार्थक होने के लिए बहुत जटिल लगता है।

इसमें दो समस्याएं हैं:

1. कोड गलत है। curried() एक सरणी स्वीकार नहीं करता है। भरने c के साथ आराम पैरामीटर [true, false] के द्वारा किया जा सकता है curried('foo', ...[true, false]) लेकिन यह इस सुझाव से टाइपप्रति में असफल हो जायेगी। हम किसी मामले के लिए टाइपिंग समाधान प्रदान करने में सक्षम नहीं हो सकते हैं, लेकिन किसी को गलत प्रदान करने के लिए हतोत्साहित किया जाता है!
2. अनजाने में, आपने वैकल्पिक और बाकी मापदंडों को जोड़ दिया, और अपने प्रस्ताव के साथ एक बग का खुलासा किया। curried() को b बिना नहीं बल्कि c साथ बुलाया जा सकता है । ऐसा करने से गलत व्यवहार होगा। टाइपस्क्रिप्ट जानता है कि curried() (...items: [string, boolean[]] | [boolean[]]) लेकिन यह सच नहीं है । क्योंकि जावास्क्रिप्ट टाइपिंग-रहित है, [true, false] से c (यह मानते हुए कि हमने उपरोक्त समस्या हल कर ली है) को curried([true, false]) करने से b से undefined सेट नहीं होगा c से [true, false] , लेकिन b से true और c से [false] !

मैं निम्नलिखित सुधारों का सुझाव देता हूं:

1. दूसरी (और आसान) समस्या के लिए, समाधान सरल है: अंतिम वैकल्पिक तर्क (यानी हमारे मामले में [number, string, boolean[]] | [number, boolean[]] ) के लिए यूनियन टपल का अनुमान न लगाएं, जब बाकी पैरामीटर हो। इसके बजाय, [number, string, boolean[]] | [number] अनुमान लगाएं - यानी, पूर्ण हस्ताक्षर के लिए एक मामला, जिसमें सभी वैकल्पिक और बाकी शामिल हैं, अंतिम को छोड़कर प्रत्येक वैकल्पिक के लिए एक, और अंतिम और शेष के बिना एक।
2. पहली समस्या अधिक जटिल है: आप पहले ही कह चुके हैं कि आपको लगता है कि यह सार्थक होने के लिए बहुत जटिल है। मुझे लगता है कि बाकी मापदंडों की लोकप्रियता को देखते हुए यह _is_ सार्थक है, लेकिन यह पहली समस्या (जीत! ) के कारण _necessary_ है। मुझे लगता है कि यह अच्छा होगा यदि हम tuple-with-last-rest-array (मैं सिंटैक्स के बारे में सोचता हूं [t1, t2, t3, ...arr] ) के लिए इंटरफ़ेस को उजागर करता हूं, लेकिन हमें इसकी आवश्यकता नहीं है। हम इसके साथ एक आंतरिक के रूप में रह सकते हैं (हाहा, आपको अभी भी एक आईडीई में प्रकार को प्रदर्शित करने के तरीके से निपटना होगा)।

लेकिन तमाम शिकायतों और उकसावे के बाद बढ़िया प्रस्ताव! धन्यवाद (बस आपको शांत करने के लिए, यह GitHub में अब तक का पहला मुद्दा है जिसका मैंने तीन इमोजी - 👍, और ❤️ के साथ जवाब दिया)।

यह वास्तव में कोणीय इंजेक्टर में उपयोगी होगा जिसे वर्तमान में any https://github.com/angular/angular/issues/37264 का उपयोग करना है

इस उदाहरण में ए, बी, सी को एकल ...A वैरिएडिक जेनेरिक प्रकार के रूप में दर्शाया जा सकता है। लेकिन मुझे नहीं पता कि यह किसी ऐसी चीज के लिए कैसे मैप करेगा जहां वैरिएडिक जेनेरिक का प्रत्येक तत्व दूसरे प्रकार ( Type ) में संलग्न होगा। शायद एक सहायक प्रकार के साथ? या सिंटैक्स को ...Type<A> जैसी किसी चीज़ की अनुमति देनी चाहिए?

export declare interface TypedFactoryProvider<T, A, B, C> {
    provide: Type<T | T[]> | InjectionToken<T | T[]>;
    multi?: boolean;
    useFactory: (a: A, b: B, c: C) => T;
    deps: [Type<A>, Type<B>, Type<C>];
}

(संदर्भ: Provider का कार्यान्वयन उस क्रम में उस फ़ैक्टरी फ़ंक्शन में deps उदाहरणों को इंजेक्ट करेगा। एक सख्त टाइपिंग यह सुनिश्चित करेगी कि डेवलपर जानता है कि क्या इंजेक्ट किया जाएगा और किस क्रम में।)

जब यह हो जाए तो कृपया String.prototype.replace के दूसरे पैरामीटर को अपडेट करना याद रखें, ताकि अंत में टाइपस्क्रिप्ट में उचित टाइपिंग हो सके!

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#Specifying_a_function_as_a_parameter

@ ग्रिफोर्क आपको एहसास है कि रेगेक्स को यह पता लगाने की आवश्यकता होगी कि उसके पास कितने कैप्चर समूह हैं, है ना?

यह वास्तव में कोणीय इंजेक्टर में उपयोगी होगा जिसे वर्तमान में any कोणीय/कोणीय#37264 का उपयोग करना है

इस उदाहरण में ए, बी, सी को एकल ...A वैरिएडिक जेनेरिक प्रकार के रूप में दर्शाया जा सकता है। लेकिन मुझे नहीं पता कि यह किसी ऐसी चीज के लिए कैसे मैप करेगा जहां वैरिएडिक जेनेरिक का प्रत्येक तत्व दूसरे प्रकार ( Type ) में संलग्न होगा। शायद एक सहायक प्रकार के साथ? या सिंटैक्स को ...Type<A> जैसी किसी चीज़ की अनुमति देनी चाहिए?

export declare interface TypedFactoryProvider<T, A, B, C> {
  provide: Type<T | T[]> | InjectionToken<T | T[]>;
  multi?: boolean;
  useFactory: (a: A, b: B, c: C) => T;
  deps: [Type<A>, Type<B>, Type<C>];
}

(संदर्भ: Provider का कार्यान्वयन उस क्रम में उस फ़ैक्टरी फ़ंक्शन में deps उदाहरणों को इंजेक्ट करेगा। एक सख्त टाइपिंग यह सुनिश्चित करेगी कि डेवलपर जानता है कि क्या इंजेक्ट किया जाएगा और किस क्रम में।)

@AlexAegis

मुझे लगता है कि इसे कुछ इस तरह टाइप किया जाएगा:

export declare interface TypedFactoryProvider<T, ...P> {
  provide: Type<T | T[]> | InjectionToken<T | T[]>;
  multi?: boolean;
  useFactory: (...providers: ...P) => T;
  deps: [...Type<P>];
}

यह समस्या अब TS 4.0 के लिए निर्धारित #39094 द्वारा ठीक कर दी गई है।

यदि यह 4.0 के साथ आ रहा है, तो अब हमारे पास इसे 4.0 नाम देने का एक कारण है
यह वास्तव में एक प्रमुख नई विशेषता है

यह भी खूब रही! शाब्दिक स्ट्रिंग प्रकारों के लिए केवल "बाएं" समान है

@sandersn मैं इस बारे में सोचने की कोशिश कर रहा हूं कि इस वाक्यविन्यास का उपयोग RxJS जैसी चीजों में कैसे किया जाएगा, जहां pipe विधि पैरामीटर एक दूसरे पर निर्भर हैं,

pipe(map<T, V>(...), map<V, U>(...), filter(...), ...) । आप इसे इस तरह से कैसे टाइप करेंगे जो वे अब नहीं करते हैं? (विभिन्न भिन्न लंबाई टाइपिंग की दर्जनों पंक्तियाँ)

@gioragutt ने PR का उपयोग करते हुए @ahejlsberg ने प्रस्तुत किया मुझे लगता है कि यह काम करेगा लेकिन मैं गलत हो सकता हूं हालांकि

type Last<T extends readonly unknown[]> = T extends readonly [...infer _, infer U] ? U : undefined;

interface UnaryFunction<T, R> { (source: T): R; }

type PipeParams<T, R extends unknown[]> = R extends readonly [infer U] ? [UnaryFunction<T, U>, ...PipeParams<R>] : [];

function pipe<T, R extends unknown[]>(...fns: PipeParams<T, R>): UnaryFunction<T, Last<R>>;

गोलाकार प्रकार की त्रुटि के कारण @tylorr काफी काम नहीं करता है।

हालांकि, सामान्य कामकाज काम करता है ।

type Last<T extends readonly unknown[]> = T extends readonly [...infer _, infer U] ? U : undefined;

interface UnaryFunction<T, R> { (source: T): R; }

type PipeParams<T, R extends unknown[]> = {
    0: [],
    1: R extends readonly [infer U, ...infer V]
    ? [UnaryFunction<T, U>, ...PipeParams<U, V>]
    : never
}[R extends readonly [unknown] ? 1 : 0];

declare function pipe<T, R extends unknown[]>(...fns: PipeParams<T, R>): UnaryFunction<T, Last<R>>;

@isiahmeadows यह मेरे लिए काम नहीं कर रहा है। मैं
खेल का मैदान उदाहरण ।

मुझे काम करने के करीब कुछ मिला है लेकिन यह प्रकारों को कम नहीं करेगा।
खेल का मैदान उदाहरण

मुझे बदलना पड़ा
R extends readonly [unknown] ? 1 : 0
प्रति
R extends readonly [infer _, ...infer __] ? 1 : 0

यकीन नहीं है कि क्यों

@tylorr @treybrisbane संबंधित हो सकता है: https://github.com/microsoft/TypeScript/pull/39094#issuecomment -645730082

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

वैरिएडिक टपल प्रकार भाषा के लिए एक बढ़िया अतिरिक्त हैं, प्रयास के लिए धन्यवाद!

ऐसा लगता है, curry जैसे निर्माण भी लाभान्वित हो सकते हैं (बस स्टेजिंग खेल के मैदान के साथ परीक्षण किया गया):

// curry with max. three nestable curried function calls (extendable)
declare function curry<T extends unknown[], R>(fn: (...ts: T) => R):
  <U extends unknown[]>(...args: SubTuple<U, T>) => ((...ts: T) => R) extends ((...args: [...U, ...infer V]) => R) ?
    V["length"] extends 0 ? R :
    <W extends unknown[]>(...args: SubTuple<W, V>) => ((...ts: V) => R) extends ((...args: [...W, ...infer X]) => R) ?
      X["length"] extends 0 ? R :
      <Y extends unknown[]>(...args: SubTuple<Y, X>) => ((...ts: X) => R) extends ((...args: [...Y, ...infer Z]) => R) ?
        Z["length"] extends 0 ? R : never
        : never
      : never
    : never

type SubTuple<T extends unknown[], U extends unknown[]> = {
  [K in keyof T]: Extract<keyof U, K> extends never ?
  never :
  T[K] extends U[Extract<keyof U, K>] ?
  T[K]
  : never
}

type T1 = SubTuple<[string], [string, number]> // [string]
type T2 = SubTuple<[string, number], [string]> // [string, never]

const fn = (a1: number, a2: string, a3: boolean) => 42

const curried31 = curry(fn)(3)("dlsajf")(true) // number
const curried32 = curry(fn)(3, "dlsajf")(true) // number
const curried33 = curry(fn)(3, "dlsajf", true) // number
const curried34 = curry(fn)(3, "dlsajf", "foo!11") // error

जेनेरिक फ़ंक्शन हालांकि उपरोक्त करी के साथ काम नहीं करता है।

मुझे विश्वास नहीं है कि यह पीआर इस विशेष मुद्दे को हल करता है।

पीआर के साथ यह काम करता है

function foo<T extends any[]>(a: [...T]) {
  console.log(a)
}

foo<[number, string]>([12, '13']);

लेकिन जहां तक ​​मैं देखता हूं, यह मुद्दा इसके लिए एक कार्यान्वयन देखना चाहता है:

function bar<...T>(...b: ...T) {
  console.log(b)
}

bar<number, string>(12, '13');

वहाँ बहुत सारे कोण कोष्ठक हैं, थोड़ा बेमानी लगता है।

@AlexAegis मुझे यकीन नहीं है कि मुझे "बाकी प्रकार के पैरामीटर" में बहुत अधिक मूल्य दिखाई देता है। आप पहले से ही ऐसा कर सकते हैं:

declare function foo<T extends any[]>(...a: T): void;

foo(12, '13');  // Just have inference figure it out
foo<[number, string]>(12, '13');  // Expclitly, but no need to

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

@ahejlsberg मैं देखता हूँ। मैं पूछ रहा था क्योंकि कुछ पुस्तकालयों (जैसा कि बताया गया है) ने इस कार्यक्षमता को प्रदान करने के लिए कामकाज का इस्तेमाल किया। लेकिन यह सीमित है।

bar<T1>(t1: T1);
bar<T1, T2>(t1: T1, t2:T2);
bar<T1, T2, T3>(t1: T1, t2:T2, t3: T3, ...t: unknown) { ... }

तो अब वे या तो उसी पर टिके रहते हैं, या उपयोगकर्ताओं को ब्रैकेट टाइप करने के लिए कहते हैं, जो एक ब्रेकिंग बदलाव है, न कि सहज ज्ञान युक्त।

मैंने इस उदाहरण का उपयोग करने का कारण यह है कि यहाँ यह सीधा है कि मैंने उस टपल के प्रकार को परिभाषित किया है। एक वर्गाकार कोष्ठक यहाँ, एक वहाँ

foo<[number, string]>([12, '13']);

यहां यह इतना स्पष्ट नहीं है कि टपल उस बाकी पैरामीटर को संदर्भित करता है यदि आप इसे बाहर से देखते हैं

foo<[number, string]>(12, '13'); 

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

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

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

(क्या अब हम एक बग पर एक नज़र डाल सकते हैं जो चौराहे के प्रकार को एकीकृत करता है
सशर्त प्रकार में अनुमानित चर सबसे दाहिने चौराहे का प्रकार देता है
तर्क, या सरणियों का संघ कृपया संघ की सरणी नहीं है? हम अभी भी
टाइप सिस्टम में प्रमुख शोस्टॉपर हैं।)

शुक्र, जून १९, २०२०, १०:४१ ग्योरी सैंडोर नोटिफिकेशन @github.com पर लिखा है:

@ahejlsberg https://github.com/ahejlsberg मैं देख रहा हूँ। मैं पूछ रहा था क्योंकि
कुछ पुस्तकालयों (जैसा कि उल्लेख किया गया है) ने इसे प्रदान करने के लिए वर्कअराउंड का उपयोग किया है
कार्यक्षमता। लेकिन यह सीमित है।

छड़(t1: T1);बार(t1: T1, t2:T2); बार(t1: T1, t2:T2, t3: T3, ...t: अज्ञात) {...}

तो अब वे या तो उसी के साथ चिपके रहते हैं, या उपयोगकर्ता कोष्ठक टाइप करते हैं,
जो इतना सहज नहीं है।

मैंने इस उदाहरण का उपयोग करने का कारण यह है कि यहाँ यह सीधा है
कि मैंने उस टपल के प्रकार को परिभाषित किया है। एक वर्गाकार कोष्ठक यहाँ, एक वहाँ

फू <[संख्या, स्ट्रिंग]> ([12, '13']);

यहाँ यह इतना स्पष्ट नहीं है कि टपल उस बाकी पैरामीटर को संदर्भित करता है if
आप इसे बाहर से देखें

फू <[संख्या, स्ट्रिंग]>(12, '13');

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

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

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

इस तरह की सबसे सामान्य अवधारणा निश्चित रूप से आश्रित प्रकारों को पूरी तरह से लागू करने के लिए होगी, जिससे बाकी सब कुछ प्राप्त किया जा सकता है, लेकिन इतना दूर जाना आवश्यक नहीं है:
जैसा कि सी ++ और, कुछ हद तक, जंग ने दिखाया है, कुछ बड़े पैमाने पर, लगातार अवधारणाएं आपको मुफ्त में कई सुविधाएं प्रदान करती हैं।
यह ओकैमल और हास्केल (और मुझे लगता है कि एफ #?) के समान है, केवल प्रकार के स्तर पर, मूल्य स्तर पर किया है।

टाइप लेवल प्रोग्रामिंग से डरने की कोई बात नहीं है जब तक कि इसे विशिष्ट सुविधाओं को प्रदान करने के लिए भाषा में डिज़ाइन किया गया है।
सी ++ 14/17 में सुविधाएं उनके सिंटैक्स को छोड़कर बहुत सहज हैं, जो विशुद्ध रूप से ऐतिहासिक सामान के कारण है।

मूल डिजाइन में व्यापक अवधारणाओं को जोड़ा जा सकता था। डिजाइन के बाद
गलती पहले ही हो चुकी थी, भारी जोखिम उठाये बिना निरंतरता नहीं जोड़ी जा सकती
पीछे की असंगति। मैं भाषा डिजाइन के संबंध में संदेह से सहमत हूं:
एक संपूर्ण (टीएस अकादमिक द्वारा निर्धारित मानकों से काफी दूर है, कोई भी नहीं कर सकता
इससे असहमत)। बहुत सारी बग और विसंगतियां हैं जो हैं
लाखों उत्पादन कोड आधारों की नींव। केवल तथ्य यह है कि
डेवलपर्स भाषा में उपयोगी परिवर्धन के साथ आने में सक्षम हैं
उन बगों को गलती से ठीक किए बिना, मेरी विनम्र राय में, कमाल है
और सम्मान का पात्र है। TS की डिज़ाइन जटिलताएँ यहाँ C++ जैसी ही हैं, लेकिन इसकी
अभिव्यंजक प्रकार की प्रणाली स्थिति को बदतर बना देती है।

शुक्र, जून १९, २०२०, १२:४७ को बेनेट पीटर नोटिफिकेशन @github.com ने लिखा:

मैं निश्चित रूप से उनके कैलिबर के करीब नहीं हूं, लेकिन मैं सम्मानपूर्वक असहमत हूं
@ahejlsberg https://github.com/ahejlsberg के साथ।
मेरे अनुभव में, टाइपस्क्रिप्ट की अधिकांश जटिलताएँ से आती हैंतथ्य यह है कि बहुत सारी (सुनिश्चित करने के लिए दिलचस्प और उपयोगी) विशेषताएं हैंउनकी अपनी अवधारणाओं के रूप में विशेष-आवरण।

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

इस तरह की सबसे सामान्य अवधारणा निश्चित रूप से पूरी तरह से लागू होगी
आश्रित प्रकार, जिससे बाकी सब कुछ प्राप्त किया जा सकता है, लेकिन
इतना दूर जाना जरूरी नहीं है:
जैसा कि C++ और, कुछ हद तक, रस्ट ने दिखाया है, कुछ बड़े पैमाने पर,
सुसंगत अवधारणाएँ आपको मुफ्त में ढेर सारी सुविधाएँ प्रदान करती हैं।
यह ओकैमल और हास्केल (और मुझे लगता है कि एफ #?) के समान है
मूल्य स्तर, केवल प्रकार के स्तर पर।

टाइप लेवल प्रोग्रामिंग से डरने की कोई बात नहीं है जब तक कि यह है
विशिष्ट प्रदान करने के लिए निपटने के बजाय भाषा में डिज़ाइन किया गया
विशेषताएं।
सी ++ 14/17 में सुविधाएं उनके सिंटैक्स को छोड़कर बहुत सहज हैं,
जो विशुद्ध रूप से ऐतिहासिक सामान के कारण है।

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

@ polkovnikov-ph मुझे खुशी है कि हम इस मुद्दे पर सहमत हैं :)

समाधान के लिए, मुझे लगता है कि यह अभी भी अधिक सावधानीपूर्वक डिज़ाइन किए गए प्रकार की प्रणाली की ओर बढ़ने पर विचार करने योग्य होगा। प्रमुख संस्करण आखिरकार एक चीज हैं, और विकल्प क्लस्टर में समाप्त होना है * * जो कि सी ++ 20 है - पिछले प्रयासों की 2 परतों के शीर्ष पर और भी अच्छी तरह से डिज़ाइन की गई सुविधाओं को जोड़ने का एक सराहनीय प्रयास जिसे हटाया नहीं जा सकता है, एक में वाक्यविन्यास जो पहले से ही निश्चित रूप से पार्स करने योग्य नहीं है।

यह सब इस सूत्र से हटकर है और यहां चर्चा की जा रही

उप-टाइपिंग के लिए सही दृष्टिकोण का पता लगाने में शिक्षाविदों को दशकों लग गए: एमएलसब टाइप सिस्टम केवल 6 साल पहले बनाया गया था, टाइपस्क्रिप्ट के पहली बार जारी होने के बाद। यह व्यापक अवधारणाओं के साथ वर्गों, इंटरफेस, संघ और चौराहे के प्रकारों की नींव हो सकती है।

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

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

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