44275 ने एक ConstEvaluatable विधेय जोड़ा, और WF([T; expr]) अब ConstEvaluatable(expr) , क्योंकि expr का आलसी मूल्यांकन किया जाता है (भले ही यह केवल एक पूर्णांक शाब्दिक हो)। इस विधेय को पूरा करने के लिए अभिव्यक्ति को सफलतापूर्वक मूल्यांकन करने की आवश्यकता होती है, जबकि सामान्यीकरण त्रुटि को अनदेखा करता है और केवल Unevaluated अभिव्यक्ति को छोड़ देता है, जो कि अछूता रहता है, जो कमोबेश संबद्ध प्रकार के अनुमानों के साथ होता है। मैं उम्मीद करता हूं कि समान प्रणाली जेनरिक को स्केल करने के लिए स्केल करेगी।

@EpicatSupercell ने इस पर काम करने में रुचि व्यक्त की है, मैं प्रारंभिक कार्यान्वयन के माध्यम से उन्हें सलाह दूंगा। हालाँकि, #44275 में वर्णित सीमाओं के कारण हम बहुत दूर नहीं जा सकते।

अर्थात्, हमें @nikomatsakis 'आलसी सामान्यीकरण की आवश्यकता है ताकि निरंतर अभिव्यक्तियों को दायरे में सीमाओं का निरीक्षण करने के लिए अनुमति दी जा सके (फ़ंक्शन/प्रकार परिभाषा/impl/आदि आइटम से वे हैं), चक्रीय निर्भरताओं को आधे समय के उत्पादन के बिना।

कार्यान्वयन के तरीके (अधिक प्रत्यक्ष सलाह के लिए, Gitter पर @eddyb या IRC पर eddyb तलाश करें):

• घोषणा / वाक्य रचना:
  
  
  
  • डेटा संरचनाएं: एएसटी और एचआईआर - प्रकार वाले के साथ const पैरामीटर जोड़ें
  
  
  • पार्सिंग: parse_generic_params - पार्स const IDENT: Type
  
  
  • विविध: विज़िटिंग ( एएसटी , एचआईआर ), फोल्डिंग ( एएसटी ), लोअरिंग ( एचआईआर ), एचआईआर नक्शा , DefId कलेक्टर
  
  
• घोषणा / शब्दार्थ
  
  
  
  • डेटा संरचनाएं: ty::Generics - प्रकार वाले के साथ const पैरामीटर जोड़ें
  
  
  • HIR से रूपांतरण: generics_of - ty::ConstParameterDef से hir::ConstParam ty::ConstParameterDef बनाएं
  
  
• उपयोग / नाम संकल्प
  
  
  
  • डेटा संरचनाएं: Def - const पैरामीटर के लिए एक प्रकार जोड़ें
  
  
  • नाम समाधान पास: with_type_parameter_rib - दोनों प्रकार और const जेनरिक का समर्थन करें
  
  
• उपयोग / शब्दार्थ
  
  
  
  • ConstVal - Param वैरिएंट को ty::TyParam
  
  
  • HIR से रूपांतरण: TyArray लंबाई है कि के साथ एक ExprPath कि का संकल्प लिया Def::ConstParam का उपयोग करना चाहिए ConstVal::Param के बजाय ConstVal::Unevaluated - एक ऐसी ही में फैशन कैसे Def::TyParam ty::TyParam में बदल जाता है
  
  
  • subst::Kind - &ty::Const समर्थन करें और as_const को भी चेक करें जहां as_type और as_region चेक किए गए हैं
  
  
• अनुमान
  
  
  
  • ConstVal - InferVar वैरिएंट को ty::ReVar / ty::TyInfer(TyVar(_))
  
  
  • InferCtxt - const समकक्ष int_unification_table और इसके UnifyKey निहितार्थ
  
  
  • ty::relate::{Relate,TypeRelation} - ty::Const से संबंधित समर्थन, और ConstVal::InferVar को उसी तरह से संभालें जैसे super_combine_tys इसे प्रकारों के लिए कैसे करता है
  
  

ध्यान दें कि इन सभी को अनुमति देनी चाहिए impl<T, const N: usize> Trait for [T; N] {...} , लेकिन वास्तव में एक प्रकार/फ़ंक्शन के लिए निरंतर अभिव्यक्ति पास नहीं करना चाहिए, उदाहरण के लिए ArrayVec<T, 3> ।

मैं इस पर एक स्टैब लेना चाहता हूं :)

@jplatte @eddyb इस पर कोई खबर?

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

@jplatte यह अच्छा होगा, अगर आप पुल अनुरोध को लिंक कर सकते हैं। मैं इसे खोजने में सक्षम नहीं था।

अभी तक कोई पीआर नहीं है। मेरे सारे काम यहां मिल सकते

अच्छा काम अब तक @jplatte

अब आधारभूत कार्य के लिए एक जनसंपर्क है ( Generics रिफैक्टरिंग): #45930

मुझे लगता है कि यह पहले से ही शामिल है लेकिन रैखिक बीजगणित शैली एन आयामी सरणी को अलग-अलग लंबाई के साथ संभालने के लिए सी ++ स्टाइल फोल्डिंग को संभालना अच्छा होगा, आईई 4x4 [[f64; 4]; 4] या 4x3x5x6 आयामी सरणी [[[[ f64;6];5];3];4] और दोनों के लिए विशेष तरीकों को ठीक से लपेटने और उत्पन्न करने में सक्षम हो और स्केलर्स के लिए उचित विशेषता कार्यान्वयन ठीक से आयाम वाले वैक्टर इत्यादि। देखें https://gist.github.com/huhlig /8b21850b54a75254be4b093551f8c2cb एक

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

अब अगले चरण क्या हैं कि #45930 विलय हो गया है? @jplatte

@kjaleshire अगला कदम const जेनरिक की पार्सिंग को लागू करना है (देखें @eddyb की टिप्पणी आगे)। मैंने इस पर काम शुरू कर दिया है इससे पहले कि यह स्पष्ट हो गया कि रिफैक्टरिंग में रिफैक्टरिंग आवश्यक होगी। उस पर मेरा मौजूदा काम यहां पाया जा सकता

@jplatte मेरा मानना ​​​​है कि आप @kjetilkjeka का उल्लेख करना चाहते थे।

अद्यतन के लिए धन्यवाद! मुझे यकीन है कि मैं इस सुविधा की प्रतीक्षा करने वाले एकमात्र व्यक्ति से बहुत दूर हूं। अच्छा काम करते रहें!

@jplatte अधीर नहीं होना चाहता, लेकिन क्या इस पर कोई काम हुआ है? क्या आपको मदद की ज़रूरत है? क्या किसी की मदद करनी चाहिए?

@ est31 क्षमा करें। इस पर काम करने के लिए मेरे पास कुछ समय से समय नहीं है, और मुझे पूरा यकीन नहीं है कि मेरे पास समय कब होगा। हो सकता है कि किसी और के लिए यह सबसे अच्छा हो कि मैं वहीं रहूं जहां मैंने छोड़ा था। मुझे लगता है कि पार्सिंग हिस्सा ज्यादातर किया जाता है। कोड में दो स्थान हैं जहां मुझे यकीन नहीं था कि एक सामान्य परम के कॉन्स परम होने के मामले में क्या करना है:

• https://github.com/jplatte/rust/commit/d381bbe48f6806d6ade903608256037ef6320580#diff -7fceb7ede15b205bf5ad812c31d75384R542
• https://github.com/jplatte/rust/commit/d381bbe48f6806d6ade903608256037ef6320580#diff -9694c2dab1b4140752e569e4b1ba58c4R2216

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

@jplatte ~ None पहले में और दूसरे में कुछ भी नहीं ~~ (cc @pnkfelix @nikomatsakis)

संपादित करें : किसी भी मामले में करने के लिए कुछ नहीं।

@eddyb पहले लिंक किए गए स्निपेट के लिए क्या आप सुनिश्चित हैं कि None वापस किया जाना चाहिए? मुझे समझ में नहीं आ रहा है कि यहाँ क्या हो रहा है, लेकिन मुझे ऐसा लगता है कि कुछ भी नहीं किया जाना चाहिए। यदि None लौटाया जाता है तो अन्य पैरा जो असुरक्षित हो सकते हैं उन्हें छोड़ दिया जाएगा।

@yodaldevoid क्षमा करें, आप सही हैं, मुझे नहीं पता था कि यह Generics ।

मैं इसे वहीं से चुनना चाहूंगा जहां @eddyb के परामर्श निर्देशों के माध्यम से जा रहा हूं क्योंकि मेरे पास यह देखने के लिए समय है कि मैं कहीं भी पहुंच सकता हूं या नहीं। मैं इस बिंदु पर "उपयोग / शब्दार्थ" खंड में उतर गया हूं। प्रश्न पूछने के लिए मैं शायद जल्द ही चैट में से एक को स्विंग करूंगा।

@yodaldevoid सुनकर बहुत अच्छा लगा। मैं Gitter के बारे में नहीं जानता, लेकिन IRC पर #rustc और/या #rust-internals पर आपको निश्चित रूप से बहुत मार्गदर्शन मिलेगा!

@yodaldevoid : क्या आप कुछ सहयोग के लिए तैयार होंगे? मैं इस मुद्दे की कुछ जांच भी कर रहा हूं (😅) - शायद हम एक दूसरे के काम में कमियों को भर सकते हैं। (आप देख सकते हैं कि मैंने अब तक यहां क्या किया

@varkor ऐसा लगता है कि आप

क्या इसमें कोई प्रगति हुई है?
मैं एम्बेडेड के लिए कोड लिख रहा हूं, और मुझे वास्तव में कॉन्स जेनरिक की आवश्यकता है।

@ क्वर्टी19106
इस पर प्रगति हो रही है, हालांकि धीरे-धीरे। @varkor और मैं इस पर काम कर रहे हैं और हमारे पास समय था। मैंने इस सप्ताह कुछ प्रगति की है और हम बुनियादी उपयोग के लिए सुरंग के अंत में प्रकाश देख रहे हैं।

कॉन्स्ट जेनरिक को लागू करने के अलावा, हमने (वर्कर) इसे संभव बनाने के लिए कुछ सफाई की है (देखें #48149 और #48523)। मेरा मानना ​​​​है कि वर्तमान योजना उन दो पुल अनुरोधों की प्रतीक्षा करने के लिए है जो कॉन्स जेनरिक में खींचने से पहले जाने के लिए हैं, लेकिन वर्कर इससे अधिक बात कर सकते हैं।

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

टीएल; डीआर: प्रगति हो रही है, लेकिन यह जटिल है। मैं आपको एम्बेडेड मोर्चे पर महसूस करता हूं।

"दस्तावेज़ीकरण" चेकबॉक्स के लिए, रस्टसी गाइड में कुछ प्राप्त करना बहुत अच्छा होगा।

आपके उत्तर के लिए धन्यवाद @yodaldevoid । मैं आपके काम के अंत की प्रतीक्षा करूंगा।

उन जिज्ञासुओं के लिए अपडेट करें (क्योंकि मैं भी उत्सुक था)। पुन: ऊपर उल्लिखित दो पीआर: #48523 विलय हो गया है और #48149 लगातार प्रगति कर रहा है।

@ मार्क-आईएम अच्छी चीजें! @varkor द्वारा अच्छा काम। मोटे तौर पर ईटीए कब है, क्या आप जानते हैं? :-)

@alexreg https://github.com/rust-lang/rust/issues/51192#issuecomment -394126083

चीयर्स, @ फ्लिप111।

ऐसा लगता है कि दूसरा बड़ा रिफैक्टरिंग पीआर #48149 विलय हो गया :)

/सीसी मुझे

Next @varkor PR #51880

बस एक त्वरित अपडेट देना चाहता था, जैसा कि मुझे पता है कि कुछ लोग कॉन्स्ट जेनरिक के साथ प्रगति के बारे में पूछ रहे हैं।

कुछ संदर्भ देने के लिए, मार्च में , @yodaldevoid और मेरे पास प्रारंभिक कार्यान्वयन था जो लगभग काम कर रहा था (कार्यान्वयन का बड़ा हिस्सा पूरा हो गया था, और हम कुछ शेष दुर्घटनाओं को साफ कर रहे थे)। हालाँकि, हम जिस शाखा पर काम कर रहे थे, वह प्री-मिरी थी। जब मिरी को मिला दिया गया (और बाद के कई पीआर में), निरंतर मूल्यांकन से निपटने के लिए कोड काफी बदल गया, जिसका अर्थ है कि हमने जो कुछ किया था वह पुराना हो गया था।

इसके शीर्ष पर, यह निर्णय लिया गया था कि सामान्य पैरामीटर कोड को सामान्य रूप से पठनीयता में सुधार करने के लिए कॉन्स्ट जेनरिक से निपटने से पहले साफ करने की आवश्यकता होती है, लेकिन गलतियों को भी करने के लिए जहां हम एक निश्चित मामले में कॉन्स्ट जेनरिक से निपटना भूल जाते हैं। बनाना। यह https://github.com/rust-lang/rust/pull/48523 , https://github.com/rust-lang/rust/pull/48149 में किया गया था और https://github में पूरा किया जाएगा

इस बीच, @yodaldevoid और मैं अपने मूल कार्यान्वयन को जंग में बाद के सभी परिवर्तनों के अनुकूल बनाने पर काम कर रहे हैं। इसमें कुछ समय लगा है, लेकिन हम वहाँ पहुँच रहे हैं (हालाँकि आपके पास उतना समय नहीं होने की बारहमासी समस्या है जितनी आपने उम्मीद की थी)। मुझे उम्मीद है कि इस मोर्चे पर हमें जल्द ही कुछ अच्छी खबर मिलेगी। (इस बीच, https://github.com/rust-lang-nursery/chalk अच्छी प्रगति कर रहा है, जिसे मूल रूप से वर्णित @eddyb में कुछ कठिनाइयों का

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

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

मेरा मतलब यह है कि अमूर्त कॉन्स्ट एक्सप्रेशन की समानता की जाँच करने का एक अपेक्षाकृत सरल तरीका निम्नलिखित है:

• सिंटैक्टिक समानता से स्वचालित रूप से निपटें (यानी N+1 == N+1 बॉक्स से बाहर काम करना चाहिए)
• परिभाषा के समय उपयोगकर्ता को N+M == M+N (शायद where क्लॉज में?) जैसे समीकरण जोड़ने की अनुमति दें। इन समीकरणों का उपयोग समानता जांच द्वारा किया जा सकता है (किसी प्रकार की सर्वांगसमता समाप्ति का उपयोग करके)। एक परिभाषा जो इन प्रदत्त समीकरणों का उपयोग करके चेक टाइप नहीं करती है उसे अस्वीकार कर दिया जाता है।
• एक मोनोमोर्फिक विस्तार बिंदु पर, सभी समीकरणों को वास्तव में कॉन्स्ट एक्सप्र्स की गणना करके जांचा जा सकता है, जो अब सार नहीं हैं। यहां एक डिज़ाइन विकल्प है: यदि कोई समीकरण जो false , तो या तो एक संकलन त्रुटि हो सकती है ("समीकरण स्वयंसिद्ध हैं") या विशेषता को तत्काल नहीं किया जा सकता है ("समीकरण बाधाएं हैं")
• एक पैरामीट्रिज्ड विस्तार बिंदु पर, इन समीकरणों को आगे बढ़ाया जाता है: यदि आपके पास f N द्वारा पैरामीट्रिज्ड फ़ंक्शन है जहां N+0==N , यह समीकरण एक कॉलर g में खो नहीं जाना चाहिए g कहा जाता है।

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

उदाहरण:

/// this works directly because of syntactic checks
fn add_end<T:Copy, const N: usize>(a: &[T;N], b: T) -> [T;N+1] {
  let x : [T;N+1] = [b;N+1];
  x[0..N] = a;
  x
}

/// this should work already
fn append<T:Copy, const M:usize, const N:usize>(a: &[T;M], b: &[T;N])
  -> [T;{M+N}]
{ … }

/// Here the equation M+M==N must be carried over or checked whenever this function is used
fn sum_pairwise_append<const M: usize, const N: usize>(a: &[i32, M],b: &[i32;N])-> [T;N]
  where M+M == N {
  let mut res : [i32; N] = append(a,a);
  for i in 0 .. N { res[i] += b[i] };
  res
} 


fn main() {
  let a: [i32; 2] = [1;2];
  let b: [i32; 4] = [2;4];
  let _ = sum_pairwise_append(a, b);  // need to check 2+2=4 
}

स्वयंसिद्ध के रूप में समीकरण

इसका मतलब है कि e1 == e2 हमेशा सत्य होना चाहिए, इसलिए यह वास्तव में where बाधा नहीं है बल्कि assert_eq!(e1,e2) की तरह है जिसे टाइप चेकर द्वारा उपयोग किया जा सकता है। यहां कार्यान्वयनकर्ता एक वादा करता है कि यह हमेशा सत्य होता है, और अगर वे समीकरण का खंडन करने वाले पैरामीटर प्रदान करते हैं तो उनके उपयोगकर्ताओं को संकलन त्रुटियों के लिए उजागर करता है।

बाधाओं के रूप में समीकरण

यहां एक खंड where e1 == e2 एक बाधा है जिसे इस पैरामीट्रिज्ड विशेषता/कार्य के सफल उपयोग के लिए संतुष्ट होना चाहिए। इसका मतलब है कि e1 == e2 को हमेशा धारण करने की आवश्यकता नहीं है, जो कि केवल एक डोमेन पर सही समीकरणों के लिए दिलचस्प हो सकता है, जैसे कि (x*y) / z == (y*x) / z जो z==0 लिए तत्काल विफल हो जाएगा।

@ सी-क्यूब हमारे पास पहले से ही "अंतर्निहित where क्लॉज" के लिए एक प्रणाली है, कम से कम " WF (अच्छी तरह से गठित) नियमों" से प्राप्त कार्यों के लिए, यानी यदि आप fn foo<'a, 'b>(x: &'a &'b i32) {} परिभाषित करते हैं 'b: 'a को संतुष्ट करने की आवश्यकता होती है ( WF(&'a &'b i32) -> &'b i32: 'a -> 'b: 'a की आवश्यकता के परिणामस्वरूप)।

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

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

आप जो कुछ भी वर्णन कर रहे हैं, उनमें से अधिकांश योजना बनाई गई चीज़ों के करीब हैं

@eddyb क्या आप इन योजनाओं पर चर्चा करने वाली कोई संदर्भ पोस्ट जानते हैं?

@ फ्लिप 111 शायद कुछ आरएफसी। हो सकता है कि @withboats बेहतर जानता हो।

#51880 हो गया : टाडा :: टाडा :

@withoutboats @ ओली-OBK क्या आप की तरह भाव के समुचित एकीकरण अवरुद्ध करने के बारे में सोचते हैं N + 1 (जैसे से [T; N + 1] में प्रतीकात्मक मूल्यांकन के कुछ बुनियादी रूप हो रही है पर) miri ?

मुझे लगता है कि हमारे पास इसे एन्कोड करने के लिए पहले से ही एक तंत्र होगा, जब @varkor ConstValue::{Infer,Param} जोड़ता है, हम इसका उपयोग "(उथले) वैध लेकिन अज्ञात" (प्रतीकात्मक) मानों को ट्रैक करने के लिए कर सकते हैं, और फिर मूल्य भी शामिल कर सकते हैं (मुख्य रूप से) पूर्णांक) संचालन और उसके ऊपर कॉल।

किसी भी गैर- assert नियंत्रण-प्रवाह निर्णयों के लिए अभी भी ज्ञात मूल्यों की आवश्यकता होगी, लेकिन assert को शायद AssertThen(condition, assert message, success value) रूप में संशोधित किया जा सकता है।
( condition और success value प्रतीकात्मक हो सकते हैं!)

प्रतीकात्मक मूल्यों को ty::Const में निर्यात करने में सक्षम होने का मतलब है कि हम मिरी के बाहर कुछ एकीकरण को लागू कर सकते हैं, (सबसे?) संचालन को अपारदर्शी मानते हैं।

हमें सावधान रहना होगा कि हम अनुमान चर के कुछ भी ग्रहण न करें, लेकिन उदाहरण के लिए N + 1 मुझे लगता है कि हम दो Add(Param(N), Bits(1)) एक साथ एकीकृत करने का समर्थन कर सकते हैं।

@varkor एक परीक्षण-मामला जो मुझे लगता है कि केवल आलसी सामान्यीकरण के साथ काम करना चाहिए, कोई एकीकरण नहीं:

/*const*/ fn append<const N: usize, T>(xs: [T; N - 1], x: T) -> [T; N] {
    let new = MaybeUninit::<[T; N]>::uninitialized();
    unsafe {
        let p = new.as_mut_ptr() as *mut T;
        (p as *mut _).write(xs);
        p.add(N - 1).write(x);
    }
    new.into_inner()
}

यह केवल इसलिए काम करेगा क्योंकि:

• N - 1 ठीक एक बार टाइप स्तर पर दिखाई देता
  
  
  
  • सब कुछ उस अभिव्यक्ति को संदर्भित कर सकता है, अस्पष्ट रूप से
  
  
  • ( संभावित समाधान: type ArrayWithoutLast<T, const N: usize> = [T; N - 1]; )
  
  
• यह हस्ताक्षर के भीतर एक तर्क स्थिति में है
  
  
  
  • (याद नहीं कर सकता अगर वापसी की स्थिति भी काम करेगी। @nikomatsakis?)
  
  
  • N लिए ठोस मान प्रदान करके कॉल करने वालों को यह साबित करना होगा कि यह WF है
  
  
  • "बुलबुले" WF आवश्यकता को एकीकरण / ArrayWithoutLast
  
  
  • अन्य उपयोगों के लिए " where खंड में एम्बेड करना" जैसे [T; N - 1]: Sized
    
    
    
    
    
    • where [T; N - 1]: दुरुपयोग भी कर सकते हैं (क्या आज इसे नज़रअंदाज कर दिया जाता है? आउच!)
    
    
    
    • where ArrayWithoutLast<T, N>: ... साथ एकीकरण को फिर से बायपास करें
    
    
    
  
  

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

53645

छोटा प्रश्न जो माप की इकाइयों की चर्चा से उत्पन्न होता है। यदि स्थिरांक पर सामान्य टाइप सीधे उस पर निर्भर न हो तो हमें क्या करना चाहिए? उदाहरण के लिए:

struct Foo<T, const N: usize> {
    a: T,
    // Will such array be "the way" to handle this problem?
    // Or do we want some kind of `std:marker::PhantomConstData`? (which can be a simple
    // type alias to the same array)
    // Or maybe make `PhantomData` to accept constants?
    _phantom: [(), N],
}

_प्रेत: [(), एन],

मुझे लगता है कि आपका मतलब [(); N] , लेकिन यह केवल usize लिए काम करेगा।

मुझे लगता है कि किसी विशेष marker::PhantomConst किसी भी const प्रकार की अनुमति देना समझ में आता है।

हम्म... नवीनतम टिप्पणियों को ध्यान में रखते हुए RFC को फिर से पढ़ना, मैं सोच रहा हूँ: क्या ऐसा कुछ करने की अनुमति होगी?

struct Foo<T, const V: T> {
    _phantom: PhantomConst<T, V>,
}

मैं इसे कहीं भी प्रतिबंधित नहीं देख सकता, लेकिन मैंने सोचा होगा कि यह कम से कम एक उदाहरण के लायक होगा।

@Ekleog : जहां तक ​​​​मुझे पता है, कॉन्स्ट पैरामीटर प्रकार प्रारंभ में टाइप पैरामीटर पर निर्भर नहीं हो सकते हैं (हालांकि यह निश्चित रूप से एक्सटेंशन के लिए समझ में आता है)। (यदि हम इसकी अनुमति देते हैं तो कार्यान्वयन अधिक कठिन है, इसलिए यह सबसे सरल संस्करण से शुरू करने के लिए समझ में आता है।)

इस पर प्रगति कैसी है? क्या हम एक अनुमानित समय जानते हैं जब इसे रात में मारा जाना चाहिए?

@Zauberklavier जैसे ही यह पुल अनुरोध किया जाता है। इससे उद्धृत करने के लिए:

अभी लंबा रास्ता तय करना है

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

@eddyb वही है जो मुझे RFC चर्चा से भी याद है।

@varkor तो इसका मतलब है कि @cuviper द्वारा प्रस्तावित PhantomConst इस RFC की वर्तमान स्थिति में मौजूद नहीं हो सकता ... है ना? हालांकि नवीनतम टिप्पणियां इंगित करती हैं कि वैसे भी PhantomConst की कोई आवश्यकता नहीं है।

क्या कॉन्स्ट पैरामीटर उनके शामिल प्रकार के पैरामीटर के भिन्नता को प्रभावित करते हैं?

वर्तमान में मेरा मानना ​​​​है कि कॉन्स्ट जेनरिक में उनके प्रकार में टाइप पैरामीटर नहीं हो सकते हैं।

मैं इस बारे में स्पष्ट नहीं हूं कि इसका पहला वर्किंग वर्जन क्या कर पाएगा।

उदाहरण के लिए क्या इस टिप्पणी में कोड संकलित होगा:
https://github.com/rust-lang/rfcs/pull/2581#discussion_r23043717

यदि वह कोड संकलित है, तो इसके लिए वाक्यविन्यास प्राप्त करने से पहले यह स्थिरांक के लिए बाधाओं को लागू करने का एक तरीका होगा।

@rodrimati1992 आप शायद (): IsTrue<{N < 128}> एक अलग प्रकार के बिना बस कर सकते हैं।
मुझे लगता है कि आप बाधा का पुन: उपयोग करना चाहते हैं और क्या यह वास्तव में काम करता है? (क्योंकि N < 128 एक्सप्रेशन को कॉपी करने से शुरुआत में यह काम नहीं करेगा)
मुझे लगता है कि आप trait Lt128<const N: usize> = IsTrue<{N < 128}>; उपयोग कर सकते हैं।
मुझे लगता है कि केवल where [(); 128 - N], लिखने का विकल्प भी है, मुझे लगता है (लेकिन मुझे यकीन नहीं है कि हम गारंटी देते हैं कि इससे घबराहट होगी)।

@rodrimati1992 आप शायद (): IsTrue<{N < 128}> एक अलग प्रकार के बिना बस कर सकते हैं।
मुझे लगता है कि आप बाधा का पुन: उपयोग करना चाहते हैं और क्या यह वास्तव में काम करता है? (क्योंकि N < 128 एक्सप्रेशन को कॉपी करने से शुरुआत में यह काम नहीं करेगा)
मुझे लगता है कि आप trait Lt128<const N: usize> = IsTrue<{N < 128}>; उपयोग कर सकते हैं।
मुझे लगता है कि केवल where [(); 128 - N], लिखने का विकल्प भी है, मुझे लगता है (लेकिन मुझे यकीन नहीं है कि हम गारंटी देते हैं कि इससे घबराहट होगी)।

तो, विशेषता उपनामों के साथ मैं इसे फिर से लिख सकता हूं ?:

trait AssertLessThan128<const N:usize>=
    Assert<{N<=128}, (
        Str<"uint cannot be constructed with a size larger than 128,the passed size is:",
        Usize<N>>
    ) >;

Assert . के साथ विचारविशेषता एक प्रकार में एम्बेडेड त्रुटि संदेश मुद्रित करने के लिए एक प्रकार की त्रुटि का उपयोग कर रही है, जो AssertLessThan128 के मामले में है:

(Str<"uint cannot be constructed with a size larger than 128,the passed size is:",Usize<N>>)

जो मुझे where [(); 128 - N], से अधिक सहायक होने की उम्मीद है, क्योंकि यह आपको त्रुटि संदेश में बताता है कि संकलन-समय त्रुटि क्यों हुई।

आप if !(N < 128) { panic!("...") } एक स्थिरांक में भी कर सकते हैं, मुझे लगता है?

मैंने सोचा था कि const trait बाधाओं (या कुछ इसी तरह) आने तक std::fmt आर्किटेक्चर वहां नहीं होगा?

इस चीज़ के साथ आपके पास कई मानों के साथ त्रुटि संदेश हो सकते हैं (प्रकारों में एम्बेडेड)।

हो सकता है कि इस बारे में बात करने के लिए कॉन्स्ट जेनरिक की प्रतीक्षा करना बेहतर हो, क्योंकि निष्पादन योग्य उदाहरण दिखाना आसान होगा।

@rodrimati1992 देखें https://github.com/rust-lang/rfcs/blob/master/text/2345-const-panic.md , इससे पहले const panic!() प्राप्त करने के लिए एक विशेष मामला होने जा रहा है अन्य सुविधाओं के माध्यम से संभव हो (अनुमान पर यह शायद पहले मूल्यों के कस्टम स्वरूपण की अनुमति नहीं देगा)।

@rodrimati1992 आह, मैं देख रहा हूँ, यह वास्तव में एक चतुर चाल है!

इसकी स्थिति क्या है?

अगला चरण अभी भी https://github.com/rust-lang/rust/pull/53645 AFAIK है।

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

ऑफ-विषय हो सकता है, लेकिन क्या यह टुकड़ों और संबंधित विधियों के एक प्रकार या कांटा की अनुमति देगा Item एक टुकड़ा के बजाय संकलन-समय-निश्चित-आकार सरणी हो? यह एक for लूप को एक अकाट्य पैटर्न को नष्ट करने/बाध्य करने की अनुमति देगा, जो चंक में तत्वों को चर में मैप करता है, जैसे कि for (first, second) in arr.chunks(2) जो वर्तमान में विफल रहता है, और मैं अनुमान लगा रहा हूं (बिना किसी औचित्य के) स्वीकार्य रूप से) कि यह कुछ उपयोग मामलों में अधिक अनुकूलन की अनुमति देगा।

@jeffvandyke आप विशेष रूप से ChunksExact के बारे में सोच रहे

@jeffvandyke आप विशेष रूप से ChunksExact के बारे में सोच रहे

मैं केवल एक पीआर प्रस्तावित करने से पहले इसे लागू करने और स्थिर होने की प्रतीक्षा कर रहा हूं जो ChunksExact और इसके रूपों के अतिरिक्त ऐसे एपीआई जोड़ता है :)

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

लागू किया जाना और स्थिर करना

मेरा सुझाव है कि स्थिरीकरण की प्रतीक्षा न करें क्योंकि स्थिरीकरण के

मैं अनुमान लगा रहा हूं कि यह अभी तक impl ब्लॉक के लिए काम नहीं करता है? मैंने कोशिश की

#![feature(const_generics)]

struct The<const Val: u64>();

impl<const Val: u64> The<Val> {
    fn the() {
        println!("{}", Val);
    }
}

लेकिन, जैसा कि वास्तव में चेतावनी दी गई थी, संकलक दुर्घटनाग्रस्त हो गया

thread 'rustc' panicked at 'slice index starts at 1 but ends at 0', src/libcore/slice/mod.rs:2419:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::slice::slice_index_order_fail
  10: rustc_resolve::Resolver::resolve_ident_in_lexical_scope
  11: rustc_resolve::Resolver::resolve_path
  12: rustc_resolve::Resolver::resolve_path_without_parent_scope
  13: rustc_resolve::Resolver::smart_resolve_path_fragment
  14: rustc_resolve::Resolver::smart_resolve_path
  15: <rustc_resolve::Resolver<'a> as syntax::visit::Visitor<'tcx>>::visit_ty
  16: syntax::visit::walk_generic_args
  17: syntax::visit::walk_ty
  18: rustc_resolve::Resolver::with_generic_param_rib
  19: rustc_resolve::Resolver::resolve_item
  20: rustc_resolve::Resolver::resolve_crate
  21: rustc::util::common::time
  22: rustc_interface::passes::configure_and_expand_inner
  23: rustc_interface::passes::configure_and_expand::{{closure}}
  24: <rustc_data_structures::box_region::PinnedGenerator<I, A, R>>::new
  25: rustc_interface::passes::configure_and_expand
  26: <rustc_interface::queries::Query<T>>::compute
  27: <rustc_interface::queries::Query<T>>::compute
  28: <rustc_interface::queries::Query<T>>::compute
  29: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::prepare_outputs
  30: rustc_interface::interface::run_compiler_in_existing_thread_pool
  31: <std::thread::local::LocalKey<T>>::with
  32: <scoped_tls::ScopedKey<T>>::set
  33: syntax::with_globals

त्रुटि const में impl<const Val: u64> से संबंधित है क्योंकि उस हिस्से को हटाने से अन्य त्रुटियां होती हैं लेकिन क्रैश नहीं होता है।

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

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

हालांकि, मुझे यकीन नहीं है कि मौजूदा कार्यान्वयन स्टब्स से आउट-ऑफ-बाउंड स्लाइस एक्सेस की उम्मीद की जानी चाहिए। @varkor @yodaldevoid , क्या आप देख सकते हैं?

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

क्षमा करें यदि यह प्रश्न पूछने के लिए सही जगह नहीं है, लेकिन मुझे इससे बेहतर और कहीं नहीं मिला। सिर्फ 2 प्रश्न:

1. क्या कोई एकल कार्य सशर्त रूप से स्थिर हो सकता है? उदाहरण के लिए, एक फ़ंक्शन में 2 हस्ताक्षर हो सकते हैं जैसे:

   const fn foo<A: const T>(x: T)  // `A` const implements `T`
   fn foo<A: T>(x: A)              // `A` implements `T` normally
   

   इस मामले में, foo const iff A: const T ; यदि A लागू नहीं होता है T , तो यह अभी भी बाध्यता को पूरा करता है लेकिन foo अब स्थिर नहीं है। लेखक के लिए अधिक जटिल उदाहरणों (उदा. where A::Output : Bar ) के लिए किसी भी सामान्य सीमा को निर्दिष्ट करने में सक्षम होना भी महत्वपूर्ण है। इसका एक बड़ा उदाहरण सरल अंकगणित भी है:

   // This only accepts types that const implement `T`
   const fn square_const<T: const Mul>(x: T) -> T {
     x*x
   }
   
   // This accepts types that implement `T` any way, but it is not const
   // This function behaves identically to `square_const`
   // But has a different signature and needs a different name
   fn square<T: Mul>(x: T) -> T {
     square_const(x)
   }
   
   let a: u8 = 5;
   let b: FooNumber = FooNumber::new();
   square_const(a); // `u8` const implements Mul
   square(b); // `FooNumber` implements `Mul` normally, so we need a separate function?
   

   मुझे दृढ़ता से लगता है कि ऐसा करने का एक तरीका निश्चित रूप से होना चाहिए, और मुझे आश्चर्य है कि आरएफसी में इसका उल्लेख नहीं किया गया है (जब तक कि मैंने इसे याद नहीं किया?)

2. _[कम महत्वपूर्ण]:_ क्या किसी कॉन्स्टेबल फ़ंक्शन के शरीर में यह पता लगाने का कोई तरीका होगा कि हम कंपाइल-टाइम या रन-टाइम पर चल रहे हैं या नहीं? मुझे लगता है कि cfg!() समान कुछ मैक्रो एक उपयोगी एक्सटेंशन होगा, यदि डिबगिंग के अलावा कोई अन्य कारण नहीं है। cfg!() का वर्तमान में संकलन-समय पर मूल्यांकन किया जाता है, इसलिए मुझे लगता है (/ अनुमान) कि यह जानने में सक्षम होना चाहिए कि फ़ंक्शन को कॉन्स्ट या नियमित फ़ंक्शन के रूप में उपयोग किया जा रहा है या नहीं क्योंकि वह भी संकलन पर निर्धारित किया जाता है -समय। हालाँकि यह मेरे पहले प्रश्न से कम महत्वपूर्ण नहीं है।

@ कोडर-256

1. हां, https://github.com/rust-lang/rfcs/pull/2632 देखें।
2. मुझे यकीन नहीं है कि यह भी संभव होना चाहिए, हालांकि ऊपर दिए गए मुझे यकीन नहीं है कि यह आवश्यक भी है।

@ कोडर -256 ये दोनों प्रश्न कॉन्स्ट जेनरिक से संबंधित नहीं हैं, बल्कि कॉन्स्ट फंक्शन से संबंधित हैं। कॉन्स्ट जेनरिक कंपाइल-टाइम पर चलने में सक्षम होने के बजाय कॉन्स (जैसे foo<2>() ) पर जेनेरिक होने के लिए हैं। मुझे लगता है कि यही कारण है कि आपको RFC 2000 में अपने प्रश्नों के उत्तर नहीं मिले।

@rpjohnst धन्यवाद, लेकिन मुझे लगता है कि मैं अस्पष्ट हो सकता था। मैंने रस्ट-लैंग/आरएफसीएस#2632 और रस्ट-लैंग/आरएफसीएस#2000 दोनों को पहले ही देख लिया है, लेकिन मुझे पूरा यकीन है कि इसका उल्लेख किसी में भी नहीं किया गया है। (लेकिन मैं गलत हो सकता था?) मैं जो पूछ रहा हूं वह सशर्त रूप से स्थिरांक कार्य है। मेरे द्वारा लिखे गए उदाहरण देखें क्योंकि इसका वर्णन करना कठिन है।

@yodaldevoid ओह, आप सही कह रहे हैं, मुझे यह कहां पूछना चाहिए?

मैक्रो प्रश्न के लिए, मैं मानता हूं कि अब इसके लिए वास्तव में बहुत अधिक उपयोग नहीं है कि मैं इसके बारे में सोचता हूं

मैं जो पूछ रहा हूं वह सशर्त रूप से स्थिरांक कार्य है। मेरे द्वारा लिखे गए उदाहरण देखें क्योंकि इसका वर्णन करना कठिन है।

आपकी square_const परिभाषा का उपयोग square स्थान पर किया जा सकता है (अर्थात: इसे रन-टाइम पर समकक्ष हस्ताक्षर वाले फ़ंक्शन के लिए मजबूर किया जाता है)। इस व्यवहार की चर्चा के लिए https://github.com/rust-lang/rfcs/pull/2632 देखें (साथ ही, वह थ्रेड const fn और विशेषता सीमाओं के बीच किसी भी बातचीत के बारे में प्रश्न पूछने के लिए सही जगह है)।

@varkor मुझे विश्वास नहीं है कि यह मामला है (चूंकि विशेषता सीमाएं बदलती हैं), लेकिन मैं जंग-लैंग/आरएफसीएस # 2632 में पूछूंगा।

क्रैश रिपोर्ट:

कोड:

#![feature(const_generics)]

use std::marker::PhantomData;

struct BoundedU32<const LOWER: u32, const UPPER: u32> {
    value: u32,
    _marker: PhantomData<(LOWER, UPPER)>,
}

संकलक:

thread 'rustc' panicked at 'slice index starts at 1 but ends at 0', src/libcore/slice/mod.rs:2419:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.35.0-nightly (719b0d984 2019-03-13) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

@ जेज़ा : #![feature(const_generics)] साथ प्रयोग शुरू करने का समय आने पर हम एक घोषणा करेंगे (जिसके बारे में आपको सूचित किया जाएगा यदि आपने इस मुद्दे की सदस्यता ली है)।

@varkor रुको, @Jezza के उदाहरण में _marker: PhantomData<(LOWER, UPPER)> - वे दो const पैरामीटर हैं जिनका उपयोग प्रकारों के रूप में किया जाता है, rustc_resolve त्रुटि क्यों उत्पन्न नहीं की?

अच्छा बिंदु: मैं इसकी जांच करूंगा। ध्यान दें कि यह केवल #![feature(const_generics)] साथ एक समस्या है, इसलिए यह एक महत्वपूर्ण मुद्दा नहीं है (गैर-जेनेरिक कॉन्स का उपयोग करने से अपेक्षित त्रुटि उत्पन्न होती है)। हो सकता है कि यह कभी भी rustc_resolve तक न पहुंचे।

~ @eddyb : यह ICE resolve_ident_in_lexical_scope से आ रहा है, इसलिए मुझे लगता है कि यह संभवतः https://github.com/rust-lang/rust/issues/58307 से संबंधित है।~

संपादित करें: वास्तव में, शायद नहीं - ऐसा लगता है कि यह केवल macro_rules! पर लागू होता है।

छोटा किया गया:

#![feature(const_generics)]

struct S<const C: u8>(C);

"अपेक्षित प्रकार, पाया गया मान" त्रुटि उत्पन्न करने से पहले ICE को हल करें।

सूचकांक यहां सीमा से बाहर है:
https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L3919

निम्नलिखित कोड के लिए वर्तमान रात का उत्पादन "पैरामीटर N का कभी भी उपयोग नहीं किया जाता है":

struct Foo<const N: usize> { }

पिछली चर्चा से मैंने सोचा था कि संकलन को इस कोड को स्वीकार करना चाहिए। क्या यह केवल अधूरे कार्यान्वयन का एक आर्टिफैक्ट है?

@newpavlov सामान्य प्रकार के मापदंडों का उपयोग करने की आवश्यकता है, क्या कोई PhantomData<n> करने में सक्षम होना चाहिए?

मुझे लगता है कि PhantomData<[(); N]> करना पहले से ही संभव है। सुनिश्चित नहीं है कि ऐसा कुछ है जिसे हम वास्तव में लागू करना चाहते हैं, हालांकि, AFAIU के रूप में PhantomData बिंदु विचरण को चिह्नित करना है, और AFAIU में विचरण wrt की कोई धारणा नहीं है। एक स्थिरांक सामान्य पैरामीटर।

और यह तभी काम करता है जब N प्रकार का हो usize ।

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

@withboats क्या आप

मुझे नहीं पता कि इसे आरएफसी टेक्स्ट में शामिल किया गया था या नहीं

@withboats क्या आप यह

@yodaldevoid इस टिप्पणी को पहले संदर्भित किया गया था: https://github.com/rust-lang/rust/issues/44580#issuecomment -419576947। लेकिन यह RFC PR में नहीं था, बल्कि इस मुद्दे पर था।

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

@HadrienG2 प्रासंगिक टिप्पणी खोजने के लिए धन्यवाद।

@withboats मुझे वास्तव में यह उम्मीद नहीं थी कि आप इसके लिए सभी वर्षों की टिप्पणियों से

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

यहां कॉन्स्ट जेनरिक पर अब तक की प्रगति का सारांश दिया गया है।

कॉन्स्ट जेनरिक पर काम ठीक से शुरू होने से पहले, कुछ रिफैक्टरिंग की जरूरत थी। @jplatte ने https://github.com/rust-lang/rust/pull/45930 के साथ कार्य संभाला @jplatte ने कॉन्स्ट जेनरिक के मुख्य कार्यान्वयन पर

@yodaldevoid और मैंने उठाया जहां @jplatte छोड़ा था, लेकिन जल्दी से पाया कि प्रगति करना सामान्य रूप से सामान्य मानकों को संभालने के तरीके से https://github.com/rust-lang/rust/pull/48149 , https://github.com/rust-lang/rust/pull 48452 , https://github.com/rust-lang/rust/pull/48523 , https://github.com/rust-lang/rust/pull/51880।

इसके साथ, कॉन्स्ट जेनरिक का कार्यान्वयन बयाना में शुरू हो सकता है। तब से, @yodaldevoid और मैं धीरे-धीरे लेकिन निश्चित रूप से कॉन्स्ट जेनरिक के लिए समर्थन जोड़ रहे हैं: https://github.com/rust-lang/rust/pull/58191 , https://github.com/rust-lang/rust /pull/58503 , https://github.com/rust-lang/rust/pull/58581 , https://github.com/rust-lang/rust/pull/58583 , https://github.com/rust -लैंग/रस्ट/पुल/59170 , https://github.com/rust-lang/rust/pull/59355 , https://github.com/rust-lang/rust/pull/59415 , https://github .com/rust-lang/rust/pull/60058 , https://github.com/rust-lang/rust/pull/60280 , https://github.com/rust-lang/rust/pull/60284 और अधिकांश हाल ही में https://github.com/rust-lang/rust/pull/59008। (इन्हें ज्यादातर मुख्य कॉन्स्ट जेनरिक पुल अनुरोध से अलग कर दिया गया है।)

अभी क्या स्थिति है? कुछ कास्ट जेनरिक परीक्षण अब काम करते हैं हालाँकि, अभी भी ऐसे हैं जो नहीं करते हैं, और पूरे कोड में कई FIXME s हैं जिन्हें हमें अभी भी संबोधित करना है। हालाँकि, हम अब करीब आ रहे हैं, और हम उस अवस्था में हैं जहाँ कुछ कम लटके हुए फल हैं यदि आप मदद करना चाहते हैं।

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

कॉन्स्ट जेनरिक उचित परीक्षण के लिए तैयार होने से पहले, मैंने कुछ शेष कार्यान्वयन मुद्दों का एक सिंहावलोकन लिखा है, शीर्ष पोस्ट में, क्या करना बाकी है इसका एक मोटा विचार देने के लिए।

इसमें समय लगा है, लेकिन हम लगातार प्रगति कर रहे हैं और उम्मीद है कि हम गति बनाए रखेंगे। यह अंततः चीजों को जगह में गिरते हुए देखने के लिए प्रेरित कर रहा है!

मैं इस पोस्ट के लिए महीनों से उम्मीद कर रहा हूं @varkor :) मैं कोई जंग जादूगर नहीं हूं लेकिन मैं FIXME एस में से एक से निपटना चाहता हूं

बधाई हो @jplatte , @yodaldevoid और @varkor। गणित के कामों में कस्टम Array-like लक्षणों से छुटकारा पाने के लिए यह एक बहुत बड़ा कदम है।

आमने सामने...

@varkor परीक्षणों के संबंध में, शायद यह जानने में मदद मिलेगी कि क्या काम करने की उम्मीद है। उदाहरण के लिए, मुझे आश्चर्य हुआ कि यह काम नहीं करता: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d84ffd15226fcffe02c102edb8ae5cf1

इसके अलावा, FIXME में रुचि रखने वालों के संदर्भ के लिए: https://oli-obk.github.io/fixmeh/

@ मार्क-आईएम {} आसपास FOO डालने का प्रयास करें। ऐसे में यह काम करेगा।

उद्धरण https://github.com/rust-lang/rfcs/blob/master/text/2000-const-generics.md :

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

{expression} केवल तभी आवश्यक होना चाहिए जब अभिव्यक्ति पहचानकर्ता या शाब्दिक नहीं है, वह एक बग है।

उसी RFC का हवाला देते हुए:

पहचान अभिव्यक्ति: एक अभिव्यक्ति जिसका आगे मूल्यांकन नहीं किया जा सकता है, इसे दायरे में नामों के साथ प्रतिस्थापित करके। इसमें सभी अक्षर के साथ-साथ सभी पहचानकर्ता शामिल हैं - जैसे 3, "हैलो, वर्ल्ड", foo_bar।

: +1: धन्यवाद। मुझे अभी-अभी मिला https://github.com/rust-lang/rust/blob/ef9a876f8297e26859469b004047e0946ed10565/src/libsyntax/parse/parser.rs#L6056

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

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

अद्भुत कार्य। FIXME कुछ को ठीक करके, यदि मैं कर सकता हूं, तो मुझे सहायता करने में प्रसन्नता हो रही है। मेरे पास रस्टसी कोडबेस में अधिक अनुभव नहीं है, इसलिए मैं FIXME https://github.com/rust-lang/rust/blob/master/src/librustc_mir/monomorphize/item.rs# पर शुरू करूंगा।

निम्नलिखित कोड के बारे में क्या:

trait Foo {
    const N: usize;
    fn foo() -> [u8; Self::N];
}

वर्तमान में इसका परिणाम "वर्तमान दायरे में Self प्रकार के लिए N नामक कोई संबद्ध आइटम नहीं मिला" संकलन त्रुटि है। क्या ऐसा कोड FIXME s को पूरा करने के बाद स्वीकार किया जाएगा या इसे लागू करने के लिए अतिरिक्त प्रयास की आवश्यकता होगी?

@yodaldevoid

त्वरित प्रश्न, क्षमा करें यदि इस पर पहले ही चर्चा की जा चुकी है।

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

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

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

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

उदाहरण:

fn greet<const NAME:&'static str>(){
    println!("Hello, {}.",NAME);
}
const HIS_NAME:&'static str="John";
greet::<HIS_NAME>();
greet::<"Dave">();

ध्यान दें कि फ़ंक्शन को परिभाषित करते समय, आपको यह निर्दिष्ट करना होगा कि NAME एक स्थिरांक है, लेकिन जब आप इसे कॉल करते हैं, तो यह कहना आवश्यक नहीं है कि HIS_NAME टर्बोफिश ऑपरेटर ( ::< > ) के भीतर एक स्थिरांक है।

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

@newpavlov मुझे आश्चर्य है कि कोड काम नहीं करता है। यदि आप एक अलग मुद्दा प्रस्तुत कर सकते हैं तो इसकी सराहना की जाएगी।

@yodaldevoid @robarnold

आह, तुम्हें मिल गया। मैंने गलत तरीके से मान लिया था कि यह टाइप/फंक्शन सिग्नेचर से संबंधित है।

बिल्ट-इन सरणी प्रकारों पर कॉन्स जेनरिक का उपयोग करने के लिए, मैंने इस पर दूसरों की राय देखने के लिए #60466 खोला है।

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

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

आपको {} s को N , impl<const N: usize> Dummy<{N}> {} आसपास जोड़ना होगा।

लेकिन हाँ तब आपको अप्रतिबंधित पैरामीटर के बारे में एक त्रुटि मिलेगी।

आह, धन्यवाद। ब्रेसिज़ चीज़ के बारे में भूल गए!

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

... लेकिन हाँ, यह शायद काम करना चाहिए:

#![feature(const_generics)]

trait Dummy {}

struct Vector<const N: usize> {
    data: [f32; N],
}

impl<const N: usize> Dummy for Vector<{N}> {}

... और यह अभी भी E0207 के साथ विफल रहता है:

warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/lib.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates
 --> src/lib.rs:9:12
  |
9 | impl<const N: usize> Dummy for Vector<{N}> {}
  |            ^ unconstrained const parameter

error: aborting due to previous error

For more information about this error, try `rustc --explain E0207`.
error: Could not compile `small-matrix`.

To learn more, run the command again with --verbose.

... और मुझे लगता है कि यह वही है जो @varkor का अर्थ # 60466 में "कॉन्स्ट्स जेनरिक के लिए सरणी प्रबंधन के साथ मुद्दे" से है:

#![feature(const_generics)]

fn dummy<const N: usize>() -> [f32; N] {
    [0.; N]
}

->

warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/lib.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error: internal compiler error: cat_expr Errd
 --> src/lib.rs:3:44
  |
3 |   pub fn dummy<const N: usize>() -> [f32; N] {
  |  ____________________________________________^
4 | |     [0.; N]
5 | | }
  | |_^

error: internal compiler error: cat_expr Errd
 --> src/lib.rs:4:5
  |
4 |     [0.; N]
  |     ^^^^^^^

error: internal compiler error: QualifyAndPromoteConstants: Mir had errors
 --> src/lib.rs:3:1
  |
3 | / pub fn dummy<const N: usize>() -> [f32; N] {
4 | |     [0.; N]
5 | | }
  | |_^

error: internal compiler error: broken MIR in DefId(0/0:3 ~ small_matrix[5b35]::dummy[0]) ("return type"): bad type [type error]
 --> src/lib.rs:3:1
  |
3 | / pub fn dummy<const N: usize>() -> [f32; N] {
4 | |     [0.; N]
5 | | }
  | |_^

error: internal compiler error: broken MIR in DefId(0/0:3 ~ small_matrix[5b35]::dummy[0]) (LocalDecl { mutability: Mut, is_user_variable: None, internal: false, is_block_tail: None, ty: [type error], user_ty: UserTypeProjections { contents: [] }, name: None, source_info: SourceInfo { span: src/lib.rs:3:1: 5:2, scope: scope[0] }, visibility_scope: scope[0] }): bad type [type error]
 --> src/lib.rs:3:1
  |
3 | / pub fn dummy<const N: usize>() -> [f32; N] {
4 | |     [0.; N]
5 | | }
  | |_^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.36.0-nightly (cfdc84a00 2019-05-07) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

@HadrienG2
#60619 और #60632 देखें।

मुझे लगता है कि यह कोड बनाना चाहिए:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e45b7b5e881732ad80b7015fc2d3795c

लेकिन यह वर्तमान में त्रुटियाँ हैं:

error[E0119]: प्रकार MyArray<_, _> के लिए विशेषता std::convert::TryFrom<[type error]> के परस्पर विरोधी कार्यान्वयन:

दुर्भाग्य से यह Try{From,Into} का प्रतिबंध है और इसका कॉन्स्ट जेनरिक से कोई लेना-देना नहीं है। उन्हें कई मामलों में सामान्य रूप से लागू नहीं किया जा सकता: playpen

@oberien आपके उदाहरण में, T एक विदेशी प्रकार है, और यह ज्ञात नहीं है कि T: Into<Foo<T>> धारण करता है या नहीं।

मेरे उदाहरण में, [टी; एन] libcore में परिभाषित एक प्रकार है, और #[fundamental] (tbh मुझे यह भी नहीं पता कि इसका क्या अर्थ है), इसलिए मुझे लगता है कि विशेषता समाधानकर्ता वास्तव में जानता है [T; N]: Into<MyArray<T, {N}>> धारण नहीं करता है, और वहां एक संघर्ष नहीं होना चाहिए, मुझे लगता है?

[...] और #[fundamental] [...]

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

@varkor @yodaldevoid तो, मैं अभी एक ऐसी स्थिति में पहुँच गया हूँ जहाँ S<{N == 0}> ( S const bool पैरामीटर और N a const usize ) संकलक की नजर में न तो S<{true}> या S<{false}> है (इस अर्थ में कि यह समान लक्षणों को लागू नहीं करता है), और मुझे यकीन नहीं है कि यह एक बग है या नहीं वर्तमान प्रोटोटाइप की अपेक्षित सीमा। क्या आप मुझे वर्तमान एकीकरण तर्क पर एक त्वरित पुनश्चर्या दे सकते हैं?

एक न्यूनतम उदाहरण के रूप में, यह...

// Machinery for type level if-then-else
struct Test<const B: bool>;
trait IfFn<S, Z> { type Out; }
impl<S, Z> IfFn<S, Z> for Test<{true }> { type Out = S; }
impl<S, Z> IfFn<S, Z> for Test<{false}> { type Out = Z; }

// Returns an u8 if B is true, else an u16
fn should_be_ok<const B: bool>() -> <Test<{B}> as IfFn<u8, u16>>::Out {
    0
}

... निम्न त्रुटि उत्पन्न करता है:

error[E0277]: the trait bound `Test<B>: IfFn<u8, u16>` is not satisfied
  --> src/lib.rs:32:1
   |
32 | / fn should_be_ok<const B: bool>() -> <Test<{B}> as IfFn<u8, u16>>::Out {
33 | |     0
34 | | }
   | |_^ the trait `IfFn<u8, u16>` is not implemented for `Test<B>`
   |
   = help: the following implementations were found:
             <Test<false> as IfFn<S, Z>>
             <Test<true> as IfFn<S, Z>>

मैं वास्तव में नहीं जानता, लेकिन मुझे लगता है कि समस्या यह हो सकती है कि संकलक के पास यह तय करने का तर्क नहीं है कि 0 शाब्दिक u8 या u16 . कुछ इस तरह का प्रयास करें: 0u8 as _

ऐसा नहीं है, त्रुटि संदेश वही रहता है।

लेकिन अगर आप एक ऐसा संस्करण चाहते हैं जिसमें पूर्णांक प्रकार का अनुमान शामिल नहीं है, तो यहां एक कम से कम छोटा है:

struct Test<const B: bool>;
trait Not { const B: bool; }
impl Not for Test<{true }> { const B: bool = false; }
impl Not for Test<{false}> { const B: bool = true; }

fn should_be_ok<const B: bool>() -> bool {
    <Test<{B}> as Not>::B
}

Test<{B}> कथित रूप से Not लागू नहीं करने के कारण अभी भी विफल है।

नमस्ते ! मुझे सच में यकीन नहीं है कि कॉन्स्ट वैल्यू पर एकीकरण काम करना चाहिए या नहीं, लेकिन काम ("चाक") में एक नई एकीकरण प्रणाली है जिस पर काम किया जा रहा है लेकिन वर्तमान में rustc का उपयोग नहीं करता है।
तो आप क्या करने की कोशिश कर रहे हैं _may_ को चाक तैयार होने तक इंतजार करना होगा। और फिर भी, मुझे यकीन नहीं है कि यह काम करेगा या चाक के साथ भी काम करना चाहिए।
प्रगति के लिए https://github.com/rust-lang/rust/issues/48049 देखें।

@HadrienG2 क्या आप इसके लिए एक अलग मुद्दा

@carado एकीकरण

@HadrienG2 एक बार हमारे पास

struct Test<const B: bool>;
trait Not { const B: bool; }
impl<const B: bool> Not for Test<B> { const B: bool = false; }
impl Not for Test<{false}> { const B: bool = true; }

fn should_be_ok<const B: bool>() -> bool {
    <Test<{B}> as Not>::B
}

आप जो करना चाहते हैं वह किसी प्रकार की थकावट की जाँच है जैसे कि मैच के लिए सिर्फ विशेषता प्रणाली तक विस्तारित है। किसी सूत्र में इसका उल्लेख नहीं है।

@yodaldevoid https://github.com/rust-lang/rust/issues/61537 के रूप में फाइल किया गया।

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

ओह, मेरा बुरा तो! मुझे लगता है कि मैं वास्तव में नहीं जानता कि मैं किस बारे में बात कर रहा हूं।

कास्ट जेनरिक प्रदान करने वाली भयानक चीजों में से एक संकलन समय गणना सरल कार्य है, उदाहरण के लिए फैक्टोरियल।

उदाहरण:

fn factorial<const X: i32>() -> Option<i32> {
    match X {
        i if i < 0 => None,
        0 => Some(1),
        1 => Some(1),
        i => Some(factorial::<i - 1>().unwrap() + i)
    }
}

जहां तक ​​​​मैं समझता हूं, रात में कॉन्स जेनरिक के लिए कुछ सीमित समर्थन है? यदि हां, तो क्या इस मुद्दे से ज्यादा व्यवस्थित कोई जगह है जहां मैं इसका उपयोग और सामान ढूंढ सकता हूं?

@dancojocaru2000 const फ़ंक्शन संकलन-समय पर मूल्य-स्तरीय गणना के लिए पसंदीदा तरीका होना चाहिए, उदाहरण के लिए https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4994b7ca9cda0bfc44f5359443431378 , जो होता है काम नहीं करना है क्योंकि वे अभी तक पूरी तरह से लागू नहीं हुए हैं। लेकिन न तो const जेनरिक हैं।

आप स्निपेट समस्याग्रस्त हो सकते हैं क्योंकि मुझे यकीन नहीं है कि match को const तर्कों के लिए काम करना चाहिए या नहीं। आपने कोड में गुणन के साथ योग भी मिलाया, लेकिन यह बहुत अधिक मायने नहीं रखता।

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

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

मुझे लगता है कि अधिक उपयुक्त सुविधा होगी const fn ।

सैद्धांतिक रूप से, आपका कोड लगभग-जैसा ही काम करेगा

#![feature(const_generics)]

fn factorial<const X: i32>() -> Option<i32> {
    match X {
        i if i < 0 => None,
        0 => Some(1),
        1 => Some(1),
        i => Some(factorial::<{X - 1}>().unwrap() + i)
    }
}

fn main() {
    println!("{:?}", factorial::<10>());
}

लेकिन यह नहीं करता है:

warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/main.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error: internal compiler error: src/librustc_codegen_ssa/mir/operand.rs:79: unevaluated constant in `OperandRef::from_const`

यद्यपि आपको वास्तव में एक हस्ताक्षरित प्रकार का उपयोग करना चाहिए:

#![feature(const_generics)]

fn factorial<const X: u32>() -> u32 {
    match X {
        0 => 1,
        1 => 1,
        _ => factorial::<{ X - 1 }>() + X,
    }
}

fn main() {
    println!("{:?}", factorial::<10>());
}

क्या इस मुद्दे से ज्यादा व्यवस्थित कोई जगह है जहां मैं इसे और सामान का उपयोग कैसे कर सकता हूं?

यह आमतौर पर अस्थिर पुस्तक द्वारा कवर किया जाता

पीनो एन्कोडिंग के साथ संकलन-समय पर फैक्टोरियल,

उसके एक उदाहरण के लिए, टाइपेनम क्रेट देखें

सैद्धांतिक रूप से, आपका कोड लगभग-जैसा ही काम करेगा

factorial::<0> को कॉल करते समय _ => factorial::<{X - 1}>() * X को बहुत सही कोडजेन किया जाएगा? लेकिन ऐसा करने का प्रयास करने से एक पूर्णांक अंतर्प्रवाह हो जाएगा।

क्या मैं भविष्य में इस तरह के कोड को संकलित करने की उम्मीद कर सकता हूं?

#![feature(const_generics)]

trait NeedsDrop<const B: bool> { }
impl<T> NeedsDrop<std::mem::needs_drop<T>()> for T { }

fn foo<D: NeedsDrop<false>>(d: D) { }

यह कॉन्स्टेबल जेनरिक के रूप में N <= 32 के लिए कुछ [T; N] सरणियों के हालिया कार्यान्वयन के साथ पार कर रहा है, लेकिन निम्नलिखित कोड विभिन्न त्रुटियों के साथ रात में नवीनतम ( 4bb6b4a5e 2019-07-11 ) पर संकलित नहीं होता है the trait `std::array::LengthAtMost32` is not implemented for `[u64; _]`

#[derive(Copy, Clone, PartialEq, Eq)]
pub struct BigintRepresentation<
    const N: usize
>(pub [u64; N]) 
where [u64; N]: std::array::LengthAtMost32, 
   [u64; N*2]: std::array::LengthAtMost32;

हालांकि निम्नलिखित करता है:

#[derive(Copy, Clone, PartialEq, Eq)]
pub struct BigintRepresentation<
    const N: usize
>(pub [u64; N]) 
where [u64; N]: std::array::LengthAtMost32;

ऐसा लगता है कि N*2 इस तरह की बाधा के लिए मान्य कॉन्स्टेबल या क्वालीफायर नहीं है

@shamatar N*2 को घुंघराले ब्रेसिज़ से घिरा होना चाहिए जैसे `[u64; {एन*2}]

मुझे लगता है कि "लक्षण लागू नहीं किया गया" त्रुटियां व्युत्पन्न मैक्रोज़ से आती हैं जो [u64; {N*2}] लिए बाध्य नहीं जोड़ती हैं, लेकिन यदि व्युत्पन्न हटा दिए जाते हैं तो वर्तमान में एक आईसीई है:

```त्रुटि: आंतरिक संकलक त्रुटि: निरंतर प्रकार में एक अनदेखी त्रुटि थी: TooGeneric
--> src/main.rs:5:1
|
5 | / पब संरचना BigintRepresentation<
6 | | कॉन्स्ट एन: उपयोग करें
7 | | >(पब [u64; एन])
8 | | जहां [यू 64; एन]: एसटीडी::सरणी::LengthAtMost32,
9 | | [यू 64; {एन*2}]: एसटीडी::सरणी::LengthAtMost32;
| |________________________________________________^

थ्रेड 'rustc' ' delay_span_bug जारी किए जाने के बावजूद कोई त्रुटि नहीं हुई', src/librustc_errors/lib.rs:366:17 से घबरा गया
नोट: बैकट्रैक प्रदर्शित करने के लिए RUST_BACKTRACE=1 पर्यावरण चर के साथ चलाएं।

यह कोड संकलित नहीं करता है:

#![feature(const_generics)]

struct Foo<const X: usize>([u8; X]);

impl<const X: usize> Foo<X> {
    fn new() -> Self {
        Self([0u8; X])
    }
}

warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/lib.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error[E0573]: expected type, found const parameter `X`
 --> src/lib.rs:5:26
  |
5 | impl<const X: usize> Foo<X> {
  |                          ^
  |                          |
  |                          not a type
  |                          help: try using the variant's enum: `regex_syntax::ast::HexLiteralKind`

error[E0107]: wrong number of const arguments: expected 1, found 0
 --> src/lib.rs:5:22
  |
5 | impl<const X: usize> Foo<X> {
  |                      ^^^^^^ expected 1 const argument

error[E0107]: wrong number of type arguments: expected 0, found 1
 --> src/lib.rs:5:26
  |
5 | impl<const X: usize> Foo<X> {
  |                          ^ unexpected type argument

error: aborting due to 3 previous errors

@npmccallum आपको Foo<{X}>

@ pengowen123 हाँ, यह संकलित (साथ संकलक दुर्घटनाओं constant in type had an ignored error: TooGeneric ) के बिना derive , लेकिन तब यह एक अलग सवाल हो सकता है या नहीं, इस तरह के "डबल बाधा" प्रभावी रूप से यह है कि N <= 32 और N <= 16 कंपाइलर द्वारा लागू नहीं किया जाता है।

पैरामीटर का उल्लेख करने वाले एक्सप्रेशन शायद कुछ समय के लिए काम नहीं करेंगे, [T; N] और Foo<{N}> विशेष-केसेड हैं जिनमें N उल्लेख के साथ अभिव्यक्ति नहीं है, बल्कि बल्कि बड़े मुद्दे को दरकिनार करते हुए सीधे N पैरामीटर का संदर्भ लें।

Self का उपयोग करने से दुर्घटना होती है।
यहां तक ​​​​कि इसे Value<{C}> लिए स्वैप करने पर भी यह क्रैश हो जाता है।

#![feature(const_generics)]

struct Value<const C: usize>;

impl<const C: usize> Value<{C}> {
    pub fn new() -> Self {
        unimplemented!()
    }
}

pub fn main() {
    let value = Value::new();
}

आप स्निपेट प्लेपेन पर क्रैश नहीं होते: https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=d3fda06d2e8b3eb739afa99d5da84a33

#61338 के समान, समस्या का स्रोत वृद्धिशील संकलन है।

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

मुझे लगता है कि अधिक उपयुक्त सुविधा होगी const fn ।

सैद्धांतिक रूप से, आपका कोड लगभग-जैसा ही काम करेगा

#![feature(const_generics)]

fn factorial<const X: i32>() -> Option<i32> {
    match X {
        i if i < 0 => None,
        0 => Some(1),
        1 => Some(1),
        i => Some(factorial::<{X - 1}>().unwrap() + i)
    }
}

fn main() {
    println!("{:?}", factorial::<10>());
}

लेकिन यह नहीं करता है:

warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/main.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error: internal compiler error: src/librustc_codegen_ssa/mir/operand.rs:79: unevaluated constant in `OperandRef::from_const`

यद्यपि आपको वास्तव में एक हस्ताक्षरित प्रकार का उपयोग करना चाहिए:

#![feature(const_generics)]

fn factorial<const X: u32>() -> u32 {
    match X {
        0 => 1,
        1 => 1,
        _ => factorial::<{ X - 1 }>() + X,
    }
}

fn main() {
    println!("{:?}", factorial::<10>());
}

यह सुविधा मेरे लिए भी उपयोगी है, const fn पर्याप्त नहीं है। मैं इसे एन-आयामी सरणी के लिए आयाम = 0 की समाप्ति स्थिति के साथ उपयोग करना चाहता हूं।

मैं एक संरचना बनाने में सक्षम हूँ:

#![feature(const_generics)]
struct MyArray<T: Default, const len: usize> {
    real_array: [T; len]
}

impl<T: Default, const len: usize> MyArray<T, {len}> {
    fn new() -> Self {
        return MyArray {
            real_array: [Default::default(); len]
        }
    }
}

यह विफल रहता है क्योंकि मैं वास्तव में सरणी को प्रारंभ नहीं कर सकता क्योंकि:

error: array lengths can't depend on generic parameters
 --> src/main.rs:9:46
  |
9 |             real_array: [Default::default(); len]
  |                                              

मैंने कॉन्स्ट वैल्यू को जेनेरिक वैल्यू पर सेट करके इसके आसपास काम करने की कोशिश की है।

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

error: internal compiler error: src/librustc/ty/subst.rs:597: const parameter `height/#0` (Const { ty: usize, val: Param(height/#0) }/0) out of range when substituting substs=[]

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

भाषा को बुनियादी स्थिर जेनरिक की सख्त जरूरत है, जैसे कि मानक पुस्तकालय को सरणी के प्रत्येक आकार के लिए प्रत्येक फ़ंक्शन को परिभाषित करने की आवश्यकता नहीं है

वहाँ पहले से ही कुछ प्रयास है https://github.com/rust-lang/rust/issues/61415 ।

मुझे आशा है कि कोई भी अपना समय बर्बाद नहीं कर रहा है, यह सुनिश्चित करते हुए कि ये निराला उदाहरण काम करते हैं।

कुछ लोग करते हैं, मुझे इसमें कोई समस्या नहीं दिख रही है;)

यही एकमात्र कारण है कि मैं जंग का उपयोग नहीं करता।

यह सबसे कम दिलचस्प कारण है जिसे मैंने किसी ऐसे व्यक्ति के लिए उद्धृत किया है जो जंग का उपयोग नहीं कर रहा है। क्या आप वाकई सच कह रहे हैं?

लेकिन सरल पूर्णांक भाव पर्याप्त होने चाहिए

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

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

मुझे आशा है कि कोई भी अपना समय बर्बाद नहीं कर रहा है, यह सुनिश्चित करते हुए कि ये निराला उदाहरण काम करते हैं।

कोई नहीं है, miri पहले से ही C++ constexpr से कहीं अधिक शक्तिशाली है।
और कोई भी किसी फैंसी चीज़ पर काम नहीं कर रहा है जैसे N = M से N + 1 = M + 1 ।

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

बीटीडब्ल्यू, मुझे लगता है कि [expr; N] अभिव्यक्तियों के लिए "सरणी लंबाई सामान्य पैरामीटर पर निर्भर नहीं हो सकती" त्रुटि की आवश्यकता नहीं है, हम उसी चाल का उपयोग कर सकते हैं जो हम [T; N] प्रकारों के लिए करते हैं, और खींचते हैं एक अभिव्यक्ति के रूप में मूल्यांकन किए बिना N बाहर।

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

संपादित करें: हालांकि मुझे सामान्य रूप से सॉफ्टवेयर में काफी अनुभव है।

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

@varkor , मैं वास्तव में उपरोक्त टिप्पणी के माध्यम से अनुसरण कर रहा हूं, इसलिए यदि आपके पास कोई सलाह है, तो मैं सभी कान हूं! बेझिझक मुझे किसी अन्य संचार चैनल पर भी देखें।

एक चीज जो हम अभी कर सकते थे, मुझे अभी एहसास हुआ कि Foo::<{...}> / [expr; ...] अभिव्यक्तियों को जेनेरिक पैरामीटर ( ... भाग में) को संदर्भित करने की अनुमति है।

ऐसा इसलिए है क्योंकि अभिव्यक्तियों को शरीर के भीतर कहीं घोंसला बनाया के लिए जाता है।

हालांकि, मुझे चिंता है कि एक हस्ताक्षर में उदाहरण के लिए [(); [0; 1][0]] टूट जाएगा, इसलिए हमें शायद वैसे भी एक क्रेटर चलाने की आवश्यकता होगी (और आजकल वे हमेशा के लिए लेते हैं)।

किसी भी व्यक्ति के लिए जो कॉन्स जेनरिक के साथ मदद करने में दिलचस्पी रखता है, मेरी सलाह होगी कि ओपन कॉन्स्ट जेनरिक मुद्दों की @eddyb , @yodaldevoid , @oli-obk और मैं कई प्रासंगिक क्षेत्रों से परिचित हैं और पूछने के लिए अच्छे लोग हैं। आपकी सभी रुचियों के लिए धन्यवाद!

cc @hameerabbasi , @ranweiler

कॉन्स्ट जेनरिक के बारे में प्रश्न:

1. मुझे दस्तावेज कहां मिल सकते हैं (ताकि मुझे यहां प्रश्न पूछने की जरूरत न पड़े)
2. इस समय मनमानी प्रकार के const पैरामीटर का उपयोग करने पर कौन सी सीमाएं मौजूद हैं?
3. const जेनरिक की कौन सी महत्वपूर्ण विशेषताएं संकलक को कार्यान्वित/क्रैश नहीं कर रही हैं?

PS (योगदानकर्ता:) इस सुविधा पर काम करने के लिए आपका बहुत-बहुत धन्यवाद।

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

और कोई भी किसी फैंसी चीज़ पर काम नहीं कर रहा है जैसे N = M N + 1 = M + 1 ।

इस प्रकार की बाधाओं के लिए सॉल्वर रखना बहुत उपयोगी होगा। उदाहरण के लिए, यदि दो एन-बिट्स संख्या एक जोड़ को लागू करते हैं, तो ओवरफ्लो बिट के लिए रिटर्न आकार (एन + 1) होना चाहिए। जब (उदाहरण के लिए) दो 5-बिट नंबर दिए जाते हैं तो सॉल्वर को यह जांचना चाहिए कि N + 1 = 6 । उम्मीद है कि इसे बाद में कास्ट जेनरिक पर बोल्ट किया जा सकता है :)

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

ईमानदार होने के लिए, इस प्रकार की बाधा-आधारित समस्याओं को हल करना प्रोलॉग के लिए नौकरी की तरह लगता है। हो सकता है कि चाक इंजन पर पिग्गीबैकिंग एक विकल्प हो? अफैक यह लक्षणों को हल करता है, हालांकि, है ना?

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

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

मैं एक संरचना बनाने में सक्षम हूँ:

#![feature(const_generics)]
struct MyArray<T: Default, const len: usize> {
    real_array: [T; len]
}

impl<T: Default, const len: usize> MyArray<T, {len}> {
    fn new() -> Self {
        return MyArray {
            real_array: [Default::default(); len]
        }
    }
}

यह विफल रहता है क्योंकि मैं वास्तव में सरणी को प्रारंभ नहीं कर सकता क्योंकि:

error: array lengths can't depend on generic parameters
 --> src/main.rs:9:46
  |
9 |             real_array: [Default::default(); len]
  |                                              

मैं उसी समस्या में भाग गया, लेकिन MaybeUninit का उपयोग करके एक समाधान मिला:
https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=3100d5f7a4efd844954a6fa5e8b8c526
यह स्पष्ट रूप से उचित प्रारंभिक सरणी प्राप्त करने के लिए केवल एक कामकाज है, लेकिन मेरे लिए यह उचित तरीका उपलब्ध होने तक पर्याप्त है।
नोट: मुझे लगता है कि कोड हमेशा इरादा के अनुसार काम करना चाहिए, लेकिन अगर किसी को असुरक्षित के उपयोग के साथ कोई बग मिलती है, तो मुझे इसे ठीक करने में खुशी होगी।

@raidwas जब आप = ऑपरेटर का उपयोग अनियमित स्मृति को प्रारंभ करने के लिए करते हैं तो आप प्रारंभिक स्मृति छोड़ रहे हैं। इसके बजाय ऐसा करें,

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5d962ce7c553e850030240244608ec00

@ कृष्णासनसी धन्यवाद, अच्छी पकड़: डी (तकनीकी रूप से मैंने

तकनीकी रूप से, फ़्लोट्स को गिराना भी अपरिभाषित है, लेकिन यह अभी शोषक नहीं है।

तकनीकी रूप से, फ़्लोट्स को गिराना भी अपरिभाषित है, लेकिन यह अभी शोषक नहीं है।

मैंने उम्मीद की होगी कि किसी भी Copy प्रकार को छोड़ना, यहां तक ​​​​कि अनियमित वाले भी, एक नो-ऑप है। शायद यह बदलने लायक है।

तकनीकी रूप से, फ़्लोट्स को गिराना भी अपरिभाषित है, लेकिन यह अभी शोषक नहीं है।

मैंने उम्मीद की होगी कि किसी भी Copy प्रकार को छोड़ना, यहां तक ​​​​कि अनियमित वाले भी, एक नो-ऑप है। शायद यह बदलने लायक है।

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

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

दुर्घटनाग्रस्त होने पर अगर मैंने दूसरे टोकरे (निर्भरता) से const-param_ के साथ टाइप करने की ओर इशारा करते हुए _aliases का उपयोग किया।

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

• टोकरा ए, lib
  ```#![क्रेट_टाइप = "लिबास"]
  

  ![फीचर (const_generics)]

पब प्रकार उपनाम= संरचना;
पब संरचना संरचना(टी);

- crate B

बाहरी टोकरा टोकरा_ए;
क्रेट_ए :: उपनाम का उपयोग करें;

पब fn inner_fn(v: उपनाम) {}
```
क्रैश-लॉग (44580).txt

@fzzr- लगता है #64730

https://github.com/rust-lang/rust/issues/61624 जैसा भी लगता है

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

मेरे बहुत से उपयोग वास्तव में उन प्रकारों के लिए नहीं हैं जहां एक स्थिर मूल्य प्रकारों को निर्धारित करने में भूमिका निभाता है, बल्कि उन सुविधाओं का लाभ उठाने के लिए है जो गैर-कॉन्स्ट/शाब्दिक मूल्यों के लिए बंद हैं (अभी भी पूरी तरह से समर्थित नहीं हैं, उदाहरण के लिए मिलान पैटर्न, लेकिन अंततः होने की आवश्यकता होगी)।

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

@mqudsi क्या आप एक उदाहरण दे सकते हैं? कॉन्स्टेबल को और अधिक शक्तिशाली बनाने के लिए पहले से ही योजनाएं और चल रहे मूलभूत कार्य चल रहे हैं। हालांकि, जेनरिक को स्थिर करने के लिए यह ऑर्थोगोनल है।

मेरा मतलब यह है कि, यदि आप सामान्य पार्सर कोड को पुन: उपयोग के लिए निम्न की तरह दोबारा प्रतिक्रिया देना चाहते हैं:

let mut result: u32 = 0;
let mut digits = 0;
while digits < max_digits && src.has_remaining() {
    match src.get_u8() {
        d<strong i="6">@b</strong>'0'..=b'9' => {
            result = result*10 + (d - b'0') as u32;
            digits += 1;
        },
        b'>' => match result {
            0..=191 => break, // valid range
            _ => return Err(DecoderError::OutOfRange),
        },
        _ => return Err(DecoderError::Malformed)
    }
}

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

#[inline(always)]
fn read_str_digits<B: bytes::buf::Buf>(src: &mut B, stop_word: u8, 
    max_digits: u8, min_value: u32, max_value: u32) -> Result<u32, DecoderError> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d<strong i="10">@b</strong>'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            stop_word => match result {
                min_value..=max_value => break, // valid range
                _ => return Err(DecoderError::OutOfRange),
            },
            _ => return Err(DecoderError::Malformed)
        }
    }

    ...
}

यदि कॉन्स्ट जेनरिक कॉन्स्टेबल तर्कों से पहले लैंड करता है, तो मैं निम्नलिखित के साथ आने के लिए कॉन्स्ट जेनरिक का अचानक दुरुपयोग कर सकता हूं:

#[inline(always)]
fn read_str_digits<const MinValue: u32, const MaxValue: u32, const StopWord: u8, B: bytes::buf::Buf>
(src: &mut B, max_digits: u8) -> Result<u32, DecoderError> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d<strong i="14">@b</strong>'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            StopWord => match result {
                MinValue..=MaxValue => break, // valid range
                _ => return Err(DecoderError::OutOfRange),
            },
            _ => return Err(DecoderError::Malformed)
        }
    }

    ...
}

आज तक, यह कोड भी काम नहीं करेगा क्योंकि संकलक स्थिरांक के सामान्य मूल्यों को एक पैटर्न में उपयोग के लिए मान्य नहीं मानता है, लेकिन यह स्पष्ट रूप से गलत है और RFC 2000 के उतरने से पहले इसे संबोधित करने की आवश्यकता है। मुझे गलत मत समझो, मैं वर्षों से सामान्य स्थिरांक के लिए लड़ रहा हूं और मेरे पास एक दर्जन प्रमुख बक्से के लिए जाने के लिए पीआर तैयार हैं (मैं समय क्षेत्र को chrono एक कॉन्स्ट जेनेरिक बनाने के लिए इंतजार नहीं कर सकता और सभी विभिन्न DateTime प्रकारों को एकीकृत करें), लेकिन इम्हो यदि नकली कॉन्स्ट तर्कों के लिए कॉन्स्ट जेनरिक का दुरुपयोग करना संभव हो जाता है (जहां "कॉन्स्ट" से हमारा वास्तव में मतलब "शाब्दिक" है) तो आप व्यापक देखने जा रहे हैं इसका दुरुपयोग।

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

fwiw, इस तरह मैं कॉन्स तर्क संस्करण की तरह दिखने की कल्पना करता हूं:

#[inline(always)]
fn read_str_digits<B: Bytes>(src: &mut B, min_value: const u32, 
    max_value: const u32, stop_word: const u8, max_digits: u8) -> Result<u32, ()> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d<strong i="23">@b</strong>'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            stop_word => match result {
                min_value..=max_value => break, // valid range
                _ => return Err(()),
            },
            _ => return Err(())
        }
    }

    ...
}

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

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

यह एक उपयोग-मामले की तरह लगता है जिसे कुछ नए सिंटैक्स के साथ बाध्य चर के मानों को पैटर्न (न केवल स्थिरांक) में उपयोग करने की अनुमति देकर अधिक आसानी से संबोधित किया जाता है। तथ्य यह है कि वर्तमान में पैटर्न में कॉन्स की अनुमति है, काउंटर-सहज ज्ञान युक्त और, जहां तक ​​​​मुझे पता है, ऐतिहासिक।

@mqudsi मुझे क्षमा करें यदि यह एक मूर्खतापूर्ण प्रश्न है, लेकिन मुझे आपके द्वारा दिए गए उदाहरण के बारे में कुछ भी गलत नहीं दिख रहा है। यह मेरे लिए कॉन्स जेनरिक के लिए एक पूरी तरह से वैध उपयोग के मामले की तरह दिखता है: एक परिभाषा है जिसे अधिकतम/मिनट के रूप में मनमाने मूल्यों के साथ काम करने के लिए सामान्यीकृत किया जाता है। मुझे वास्तव में कॉन्स्ट जेनरिक पर कॉन्स्ट तर्कों के लाभ नहीं दिख रहे हैं। वे मेरे बराबर लगते हैं; यही है, कॉन्स्ट तर्कों को केवल जेनरिक का उपयोग करने के लिए एक desugaring के रूप में लागू किया जा सकता है। क्या आप विस्तार से बता सकते हैं कि इस डिज़ाइन पैटर्न में क्या गलत है?

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

• @ skinny121 पिछले महीने कॉन्स्ट जेनरिक के साथ विभिन्न बकाया मुद्दों को ठीक करने में शानदार काम कर रहा है:
  
  
  
  • परीक्षण सूट का विस्तार करना (https://github.com/rust-lang/rust/pull/60550)
  
  
  • फिक्सिंग टाइप इंफ़ेक्शन इश्यू (https://github.com/rust-lang/rust/pull/64679, https://github.com/rust-lang/rust/pull/65579)
  
  
  • स्ट्रिंग्स और स्लाइस (https://github.com/rust-lang/rust/pull/64858) और पॉइंटर्स (https://github.com/rust-lang/rust/pull/64986) सहित कॉन्स्ट जेनरिक में अधिक प्रकारों का समर्थन करना ) (हालांकि ध्यान दें कि इन्हें बाकी कॉन्स जेनरिक के साथ तुरंत स्थिर नहीं किया जा सकता है, क्योंकि वे मूल आरएफसी में समर्थित नहीं हैं)
  
  
  • कास्ट जेनरिक के साथ नैदानिक ​​मुद्दों को ठीक करना (https://github.com/rust-lang/rust/pull/65154, https://github.com/rust-lang/rust/pull/65579)
  
  
  • कॉन्स जेनरिक क्रॉस-क्रेट (https://github.com/rust-lang/rust/pull/65365) के उपयोग के साथ कई मुद्दों को ठीक करना
  
  
• @eddyb ने कॉन्स जेनरिक को प्रभावित करने वाले
• @matthewjasper ने मैक्रोज़ (https://github.com/rust-lang/rust/pull/63083) में कॉन्स्ट जेनरिक का उपयोग करने के साथ कुछ मुद्दों को ठीक किया
• @davidtwco ने कॉन्स्टेबल जेनरिक और कंस्ट्रक्टर्स (https://github.com/rust-lang/rust/pull/60839) से जुड़े एक मुद्दे को ठीक किया।
• @GuillaumeGomez ने Rustdoc (https://github.com/rust-lang/rust/pull/61605) में कॉन्स्टेबल जेनरिक का प्रदर्शन तय किया
• @varkor ने कुछ प्रकार के अनुमान के मुद्दों को ठीक किया (https://github.com/rust-lang/rust/pull/61570, https://github.com/rust-lang/rust/pull/60742, https://github. com/rust-lang/rust/pull/60508), कॉन्स्ट जेनरिक स्थानों को प्रतिबंधित करने वाला एक मुद्दा इस्तेमाल किया जा सकता है (https://github.com/rust-lang/rust/pull/60717) और विभिन्न कंपाइलर क्रैश (https:/ /github.com/rust-lang/rust/pull/61380, https://github.com/rust-lang/rust/pull/61333, https://github.com/rust-lang/rust/pull/60710 )

इसके अतिरिक्त, कंपाइलर पर अन्य काम ने कॉन्स्ट जेनरिक से संबंधित कुछ अन्य मुद्दों को ठीक किया।

हमने कंपाइलर के अंदर ही कॉन्स्ट जेनरिक का उपयोग करना भी शुरू कर दिया है: सरणी विशेषता कार्यान्वयन अब @crlf0710 और @scottmcm (https://github.com/rust-lang/rust/pull/60466, https) के काम के लिए कॉन्स्ट जेनरिक धन्यवाद का उपयोग करते हैं। ://github.com/rust-lang/rust/pull/62435), जिसके कारण प्रदर्शन में सुधार हुआ , और जो हमें भविष्य में सरणी विशेषता कार्यान्वयन को @Centril ने VecDeque (https://github.com/rust-lang/rust/pull/63061) को बेहतर बनाने के लिए उसी दृष्टिकोण का उपयोग किया।

पिछले कुछ महीनों में कॉन्स्ट जेनेरिक के साथ विशेष रूप से आम बगों में से कई को ठीक किया गया है। @nikomatsakis आलसी सामान्यीकरण की जांच कर रहा है, जो शेष मुद्दों के एक मेजबान को ठीक करना चाहिए, जबकि @jplatte प्रकार पैरामीटर से कॉन्स्ट पैरामीटर की {X} टाइप करने की आवश्यकता नहीं होगी a कॉन्स्ट तर्क)।

मैं विकास के दौरान कॉन्स्ट जेनरिक के लिए उनके सभी परामर्श और समीक्षा के लिए @eddyb को भी धन्यवाद देना चाहता हूं, जो अमूल्य रहा है।

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

@mqudsi @mark-im क्या जेनरिक के लिए मौजूदा वाक्यात्मक विकल्प का विस्तार करना उचित होगा, impl Trait तर्क स्थिति में, जेनरिक को स्थिर करने के लिए? यह सिंटैक्स @mqudsi इस उपयोग के मामले के लिए सुझाया गया है।

व्यक्तिगत रूप से मुझे लगता है कि इससे ऐसे उपयोगकेस की पठनीयता में सुधार होगा, लेकिन मुझे एक समस्या दिखाई देती है: सामान्य जेनरिक का उपयोग डेटा पास करने के लिए किया जाता है, इसलिए वे एक तर्क के लिए बाध्य हैं। यह कॉन्स्ट जेनरिक के मामले में नहीं है, तो आप उन्हें कैसे पास करेंगे? दिखाओ कि वे तर्क हैं?
तर्क की स्थिति में impl Trait के मामले में, इसका उपयोग टर्बोफिश सिंटैक्स के साथ भी नहीं किया जा सकता है। तर्क में const , यह उलटा होगा। यह भ्रमित करने वाला हो सकता है।

मुझे यकीन नहीं है कि क्या लाभ यहां "अजीबता" से अधिक हैं, लेकिन मैं वैसे भी अपने विचार साझा करना चाहता था।

मुझे पहले इस बारे में एक चर्चा याद आ गई थी, और अब मुझे यह मिल गई है: https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709

@ PvdBerg1998 जो एक बहुत बुरा विचार लगता है। मुझे वास्तव में यह विचार नहीं आया कि <…> पढ़ने के लिए एक _हार्ड सिंटैक्स_ है। यहां दो संभावनाएं:

1. आप सोचते हैं, जैसा कि मैं करता हूं, कि इसे पढ़ना मुश्किल नहीं है, यहां तक ​​कि कई सीमाओं के साथ भी।
2. आपको लगता है कि इसे पढ़ना मुश्किल है: तो शायद समाधान उन्हें where क्लॉज पर रखना होगा?

अब ऊपर लिंक किए गए प्री-आरएफसी से तुलना करें। यह एक _tag_ (टाइप-सिस्टम के अर्थ में) सीधे फ़ंक्शन तर्कों की स्थिति में पेश करेगा, यानी किसी फ़ंक्शन के शरीर के लिए परिवर्तनीय बाइंडिंग।

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

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

let r = _mm_blend_ps::<{2 * C}>(a, b);
let r = _mm_blend_ps(a, b, 2 * C);

मेरी राय में दूसरी पंक्ति की तुलना में दूसरी पंक्ति बहुत अधिक स्वाभाविक है। एक अन्य उदाहरण मैट्रिक्स निर्माण होगा: MatrixF32::new(3, 3) बनाम MatrixF32::new::<3, 3>() । मैं दृढ़ता से असहमत हूं कि यह कार्यक्षमता "बहुत भ्रमित" होगी। उपयोगकर्ता के लिए यह फ़ंक्शन तर्क के लिए अतिरिक्त आवश्यकता से अधिक कुछ नहीं है। हम मैक्रोज़ के माध्यम से पहले से ही const तर्कों का अनुकरण कर सकते हैं ( std अंदर SIMD इंट्रिनिक्स देखें), लेकिन यह काफी बदसूरत और अक्षम है।

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

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

एक बात जो const तर्कों को impl Trait तर्कों से अलग करती है (जो @PvdBerg1998 का उल्लेख किया गया है) यह है कि वे तर्क हैं, जो कि प्रकार के अनुमान के लिए हैं ।

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

यह सी ++ में काफी आम है, उदाहरण के लिए:

template <typename T, size_t N>
size_t length(T (&array)[N]) {
    return N;
}

यह बस एक स्थिरांक पैरामीटर को स्वीकार करने और एक स्थिरांक सामान्य पैरामीटर के लिए यह desugaring से आसानी से अलग है ( fn foo(const N: usize) -> fn foo<const N: usize>() )। यह एक कॉन्स जेनेरिक पैरामीटर के साथ एक पैरामीटर को बाधित करने के करीब है, और फिर तर्क से उस कॉन्स्ट जेनेरिक तर्क का जिक्र करता है। तो उपरोक्त मैट्रिक्स उदाहरण इस तरह दिख सकता है:

impl<const W: usize, const H: usize> MatrixF32<W, H> {
    fn new(w: usize<W>, h: usize<H>) -> Self { .. }
}

...जहाँ usize<X> "a usize के लिए X मान के साथ निर्मित सिंटैक्स है।" (समान रूप से, आप श्रेणीबद्ध प्रकारों के लिए usize<X..Y> चाहते हैं, जिनकी चर्चा NonZero के सामान्यीकरण के संदर्भ में की गई है।)

यदि आप श्रेणीबद्ध प्रकारों में रोपिंग से बचना चाहते हैं, तो आप आश्रित-टाइप की गई भाषाओं को देख सकते हैं, जो मापदंडों को सीधे प्रकारों में उपयोग करने की अनुमति देती हैं, जिसमें कुछ गुंजाइश है:

fn new(const W: usize, const H: usize) -> MatrixF32<W, H> { .. }

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

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

foo :: Integer -> Integer
foo 0 -- 0 has type Integer

-- but
data P (a :: Integer)

type MyP = P 10 -- 10 has kind Integer, which “value” is the 10 type

इसलिए:

fn foo<const X: usize>()

यहां, X एक मूल्य से अधिक प्रकार के समान है।

इसके अलावा, मुझे मोनोमोर्फाइजेशन की परवाह है। अगर मैं इसे पढ़ता हूं:

let x = foo(12, "Hello, world!", None);

आपके प्रस्ताव के साथ, यदि हम foo की परिभाषा को देखें, तो यह जानना कठिन है कि कौन से तर्क foo को एकरूप कर देंगे। क्योंकि हर बार जब आप एक कॉन्स जेनेरिक के लिए एक अलग मान पास करते हैं, तो आप एक पूर्ण नया फ़ंक्शन बनाते हैं।

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

आपने मुझे गलत पढ़ा होगा, मैंने विशेष रूप से कहा था " const तर्क ... तर्क हैं ," नहीं " const जेनरिक।" मेरी पहली जंग उदाहरण भी बिल्कुल DataKinds के बराबर (है usize<N> के प्रकार के स्तर के संस्करण है N )। प्रकार शुद्धता के मामले में यहां कोई समस्या नहीं है- मैं अंतर्ज्ञान के मामले में बहस नहीं कर रहा हूं बल्कि मौजूदा, स्थापित और ध्वनि प्रकार प्रणालियों के समानता से बहस कर रहा हूं।

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

(और मैं आपके इस दावे से पूरी तरह से हैरान हूं कि मैं मापदंडों और तर्कों को भ्रमित कर रहा हूं, मैं उन्हें अलग करने के लिए सावधान था।)

मुझे तुम्हारा मतलब समझ में आया लेकिन मैं अभी भी बहुत चिंतित हूं। क्योंकि _argument_ को _const_ टैग किया गया है, इसका मतलब है कि आप इसे _a value_, रनटाइम स्पीकिंग पास नहीं कर सकते। आपको इसे _constant value_ पास करने की आवश्यकता है, जो _const जेनेरिक_ पर मैप करेगा। वैसे, आपने यहां इसका उल्लेख नहीं किया है, लेकिन यदि आप 10 को एक प्रकार के रूप में मानते हैं तो यह केवल _singleton type_ का एक अनुप्रयोग है: इसका एकल संभावित मान 10 ।

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

1. मुझे नहीं लगता कि यह आवश्यक है जबकि _const जेनिक्स_ बहुत सारे मूल्य जोड़ते हैं।
2. चूंकि वे प्रकारों के समान हैं, इसलिए उन्हें वहां होना चाहिए जहां प्रकार स्थित हैं, न कि जहां चर स्थित हैं।
3. मैं वास्तव में जानना चाहूंगा कि क्यों कुछ लोग सोचते हैं कि <…> (…) से कठिन है, विशेष रूप से struct बनाम fn । वर्तमान में, struct में केवल <…> और fn में दोनों हैं, क्योंकि उन दोनों को पैरामीटर सेट किया जा सकता है।
4. तर्क स्थिति में इम्प्लांट विशेषता के साथ जो मुझे वास्तव में नापसंद था, वह यह था कि यह देखना कठिन है कि फ़ंक्शन वास्तव में किसके साथ पैरामीटर सेट करता है। जब आप foo<A, B> पढ़ते हैं, तो आप जानते हैं कि दो पैरामीटर हैं जो फ़ंक्शन परिभाषा और कार्यान्वयन के लिए तैयार होंगे।

मुझे लगता है कि आप यहां क्या करना चाहते हैं। foo(1, 3) आपके लिए foo<3>(1) से बेहतर लगता है, लेकिन मेरे लिए नहीं। इसका कारण यह है कि foo(1, 3) को रनटाइम-आधारित होने के लिए दूसरे तर्क को स्वीकार करना चाहिए और आपके द्वारा दिया गया प्रस्ताव इसे मना करता है। मैं एप्लिकेशन देख सकता हूं, हालांकि, विशेष रूप से सरणी के साथ, लेकिन मुझे वर्तमान में यह पसंद नहीं है कि यह कैसा दिखता है। मैं एक समाधान के लिए और अधिक होगा जो कहता है "यदि कोई तर्क const , तो हम एक प्रकार के चर / स्थिरांक जेनेरिक का अनुमान लगा सकते हैं।

fn foo<const N: usize>(a: usize, b: usize | N);

यह सिर्फ काल्पनिक वाक्यविन्यास है जिसे मैं अपनी बात समझाने के लिए आया हूं: यदि आप b को एक कॉन्स्टेबल मान के रूप में पास करते हैं, तो N = b और आप अपने अच्छे सिंटैक्स के साथ समाप्त होते हैं:

foo(1, 3)

यदि b एक स्थिरांक मान नहीं है, तो यह आवश्यक है कि आप N स्पष्ट रूप से पास करें:

foo<3>(1, x)

इसके अलावा, आपके प्रस्ताव के साथ इसके लिए वाक्यविन्यास क्या होगा:

fn foo<const N: usize>(x: [f32; N]);

fn new(const W: usize, const H: usize) -> MatrixF32<W, H> { .. }

यह हमें संबंधित वस्तुओं के बारे में सवाल करने के लिए प्रेरित करता है, संक्षेप में new() एसोसिएटेड फ़ंक्शन है, और इसे ठोस प्रकार से जोड़ा जाना चाहिए, कॉन्स्ट जेनेरिक आइटम्स का अर्थ है "इस प्रकार का यह परम ...", यानी आश्रित प्रकार। तो, संदर्भ में new() में कोई तर्क नहीं होना चाहिए। स्पष्ट उपयोग Type<32>::new() जैसा दिखना चाहिए। और निश्चित रूप से सभी कॉन्स्ट जेनेरिक तर्कों को योग्य होना चाहिए।

मुझे लगता है कि आप यहां क्या करना चाहते हैं। foo(1, 3) आपके लिए foo<3>(1) से बेहतर लगता है, लेकिन मेरे लिए नहीं। इसका कारण यह है कि foo(1, 3) को दूसरे तर्क को रनटाइम-आधारित होने के लिए स्वीकार करना चाहिए और आपके द्वारा दिया गया प्रस्ताव इसे मना करता है।

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

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

इसके अलावा, आपके प्रस्ताव के साथ इसके लिए वाक्यविन्यास क्या होगा:

fn foo<const N: usize>(x: [f32; N]);

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

cppcon में constexpr फ़ंक्शन पैरामीटर के बारे में बात की गई थी, जो @ PvdBerg1998 के बारे में बात कर रहा है और ऐसा लगता है कि @mark-im से जुड़े आंतरिक धागे की तरह है। ऐसा लगता है कि वहां अच्छी तरह से प्राप्त किया गया था।

यह एक अच्छे विचार की तरह लगता है, लेकिन कॉन्स्ट-जेनेरिक के लिए प्रारंभिक कार्यान्वयन प्राप्त करने के बाद इस पर काम किया जाना चाहिए

CppCon 2019: डेविड स्टोन - C++ से मेटाप्रोग्रामिंग हटाना, N का भाग 1: constexpr फंक्शन पैराम्स

संपादित करें: उस धागे में इसका उल्लेख किया गया था, यहां constexpr फ़ंक्शन पैरामीटर के लिए संबंधित पेपर है
https://github.com/davidstone/isocpp/blob/master/constexpr-parameters.md

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

अगर हम टिप्पणियों को आगे बढ़ा सकते हैं तो हम शायद करेंगे। हम इस मुद्दे को @ रस्ट-लैंग टीम के सदस्यों के लिए लॉक करना चाहते हैं और सभी ऑफटॉपिक टिप्पणियों को छिपाना चाहते हैं?

सभी डिज़ाइन चर्चा RFC रेपो पर होनी चाहिए और सभी बग रिपोर्ट अलग-अलग मुद्दों में होनी चाहिए।

cc @ रस्ट-लैंग/मॉडरेशन क्या ऐसा करने की कोई मिसाल है?

आप किसी टिप्पणी को किसी मुद्दे पर _रूपांतरित कर सकते हैं, लेकिन टिप्पणियों को स्थानांतरित नहीं कर सकते। लॉक करना ठीक है, और मैं केवल विषय टिप्पणियों को छिपा दूंगा।

नए साल की शुरुआत के साथ, मैंने सोचा कि एक और अपडेट देना अच्छा होगा जहां हम अब कॉन्स्ट जेनरिक के साथ हैं। कॉन्स्ट जेनरिक RFC को स्वीकार किए हुए 2 साल से थोड़ा अधिक समय हो गया है। पहले वर्ष (लगभग 2018) में, आम तौर पर पूरे कंपाइलर में जेनेरिक मापदंडों के संचालन में सुधार करके कॉन्स्ट जेनरिक की सुविधा के लिए बड़े रिफैक्टरिंग प्रयासों की एक श्रृंखला शुरू की गई थी। दूसरे वर्ष (लगभग 2019) में, कॉन्स्ट जेनरिक को लागू करने पर काम शुरू हुआ: पहले नंगे न्यूनतम काम करके, और फिर सुविधा की अखंडता में सुधार करके। लोगों ने संकलक में ही कॉन्स्ट जेनरिक का उपयोग करने के साथ प्रयोग करना शुरू कर दिया। इन प्रयासों का अधिक विस्तृत विवरण पहले दो अद्यतन पोस्ट में है: [1] , [2] ।

पिछले अपडेट के बाद से पिछले कुछ महीनों में अच्छी प्रगति हुई है।

• @ पतला121 :
  
  
  
  • इंक्रीमेंटल कंपाइलेशन के तहत और क्रेट भर में (https://github.com/rust-lang/rust/pull/65652) एक इश्यू ब्रेकिंग कास्ट जेनरिक को ठीक किया गया
  
  
  • डायग्नोस्टिक्स (https://github.com/rust-lang/rust/pull/65579) में कॉन्स्ट जेनरिक को प्रभावित करने वाले प्रकार के अनुमान के साथ एक बग फिक्स किया गया
  
  
  • कॉन्स्टेबल मूल्यांकन के लिए इंटरफ़ेस को फिर से तैयार किया (https://github.com/rust-lang/rust/pull/66877)
  
  
• @yodaldevoid ने टाइप और ताकि कॉन्स्टेबल पैरामीटर्स को अब {} (https://github.com/rust-lang/rust/pull/66104) में लपेटने की जरूरत न पड़े।
• एक बार आलसी सामान्यीकरण लागू होने के बाद @eddyb ने कॉन्स्ट जेनरिक के उपयोग को सरणी लंबाई के रूप में तय किया (https://github.com/rust-lang/rust/pull/66883)
• @वर्कर :
  
  
  
  • लागू किए गए structural_match कस्टम समानता जाँच के साथ प्रकारों को रोकने के लिए जाँच को कॉन्स्टेबल जेनरिक (https://github.com/rust-lang/rust/pull/65627) के रूप में उपयोग करने से रोकें।
  
  
  • कॉन्स्ट जेनरिक को ध्यान में रखने के लिए कुछ डायग्नोस्टिक्स को ठीक किया (https://github.com/rust-lang/rust/pull/65614)
  
  
  • विभिन्न रिफैक्टरिंग और टाइप इंट्रेंस फिक्सिंग (https://github.com/rust-lang/rust/pull/65643, https://github.com/rust-lang/rust/pull/65660, https://github. कॉम/जंग-लंग/जंग/पुल/65696
  
  

कॉन्स्ट जेनरिक के साथ मदद करने वाले सभी लोगों को बहुत-बहुत धन्यवाद!

आगे क्या होगा? इस समय कॉन्स्ट जेनरिक के लिए सबसे बड़ा अवरोधक आलसी सामान्यीकरण है , जो कुछ प्रकार की कॉन्स्ट जेनेरिक सीमाओं (जैसे सरणियों में ) के लिए आवश्यक है। @ skinny121 वर्तमान में आलसी सामान्यीकरण की हटा रहा है। यह कॉन्स्ट जेनरिक के साथ कई मौजूदा मुद्दों को संबोधित करेगा।

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

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

अब हम वर्ष के आधे से अधिक हो गए हैं, इसलिए मैं संक्षेप में उस कार्य को संक्षेप में बताऊंगा जो चल रहा है। पिछले 6 महीनों में बहुत सारे लोग कॉन्स्टेबल जेनरिक समर्थन में सुधार करने में शामिल हुए हैं, इसलिए किसी भी तरह से मदद करने वाले सभी लोगों को धन्यवाद! मैं विशेष रूप से @ skinny121 और @lcnr को धन्यवाद देना चाहता स्थिरांक के लिए आलसी सामान्यीकरण और विधि कॉल में तर्क समर्थन , साथ ही साथ कई कठिन बगों को ठीक करना। उनके प्रयास नीचे दिए गए सारांश से स्पष्ट हैं।

कॉन्स्ट जेनरिक का उपयोग अब पूरे कंपाइलर में कई जगहों पर किया जा रहा है, और कॉन्स्ट जेनरिक का उपयोग करने वाले लक्षणों और कार्यों के साथ पहले से ही प्रयोग किया जा रहा है, जैसे slice::array_chunks और IntoIterator और FromIterator लिए [T; N] (https://github.com/rust-lang/rust/pull/65819, https://github.com/rust-lang/rust/pull/69985)। सरणी विशेषता कार्यान्वयन के लिए लंबाई 32 प्रतिबंध भी अंततः हटाने के लिए तैयार किया जा रहा है।

वर्तमान में हम कॉन्स्ट जेनरिक के एक

• @ पतला121 :
  
  
  
  • आलसी सामान्यीकरण के पहले संस्करण को लागू किया (https://github.com/rust-lang/rust/pull/68505, https://github.com/rust-lang/rust/pull/69181, https://github. com/rust-lang/rust/pull/67717, https://github.com/rust-lang/rust/pull/67890)
  
  
  • बेहतर प्रदर्शन (https://github.com/rust-lang/rust/pull/68118)
  
  
  • विभिन्न त्रुटियों को ठीक किया गया (https://github.com/rust-lang/rust/pull/68143)
  
  
• @एलसीएनआर :
  
  
  
  • विधियों के लिए प्रकार तर्कों में स्पष्ट कास्ट जेनरिक के लिए जोड़ा गया समर्थन (https://github.com/rust-lang/rust/pull/74113)
  
  
  • स्थिरांक के लिए आलसी सामान्यीकरण का पहला कार्यान्वयन पूरा किया (https://github.com/rust-lang/rust/pull/71973) @ skinny121 के साथ
  
  
  • unused_braces लिए एक लिंट जोड़ा गया (https://github.com/rust-lang/rust/pull/70081)
  
  
  • पैटर्न में कास्ट जेनरिक के साथ फिक्स्ड मुद्दा (https://github.com/rust-lang/rust/pull/70562)
  
  
  • dyn Trait कांस्ट जेनेरिक मापदंडों के लिए मना किया (https://github.com/rust-lang/rust/pull/71038)
  
  
  • बेहतर सुंदर-मुद्रण (https://github.com/rust-lang/rust/pull/72052)
  
  
  • फिक्स्ड विभिन्न त्रुटियां (https://github.com/rust-lang/rust/pull/70032, https://github.com/rust-lang/rust/pull/70107, https://github.com/rust- lang/rust/pull/70223, https://github.com/rust-lang/rust/pull/70249, https://github.com/rust-lang/rust/pull/70284, https://github. com/rust-lang/rust/pull/70319, https://github.com/rust-lang/rust/pull/70541, https://github.com/rust-lang/rust/pull/72066, https: //github.com/rust-lang/rust/pull/74159)
  
  
  • रिफैक्टरिंग (https://github.com/rust-lang/rust/pull/70478)
  
  
  • जोड़े गए परीक्षण (https://github.com/rust-lang/rust/pull/74392, https://github.com/rust-lang/rust/pull/74445)
  
  
• @eddyb :
  
  
  
  • सरणी लंबाई में स्थिरांक जेनरिक के साथ फिक्स्ड मुद्दे (https://github.com/rust-lang/rust/pull/70452)
  
  
  • बेहतर सुंदर-मुद्रण (https://github.com/rust-lang/rust/pull/71232)
  
  
  • बेहतर त्रुटि प्रबंधन (https://github.com/rust-lang/rust/pull/71049)
  
  
  • रिफैक्टरिंग (https://github.com/rust-lang/rust/pull/70164)
  
  
• @Aaron1011 : क्रॉस-क्रेट कॉन्स्ट जेनरिक उपयोग के साथ निश्चित त्रुटि (https://github.com/rust-lang/rust/pull/72600)
• @petrochenkov : नाम समाधान और कॉन्स्ट जेनरिक के साथ निश्चित मुद्दे (https://github.com/rust-lang/rust/pull/70006)
• @yodaldevoid : समाधान (https://github.com/rust-lang/rust/pull/74051)
• @contrun : एक ICE तय किया (https://github.com/rust-lang/rust/pull/69859)
• @ ओली-ओबीके: रिफैक्टरिंग (https://github.com/rust-lang/rust/pull/69981)
• @Centril : बेहतर निदान (https://github.com/rust-lang/rust/pull/70261)
• @DutchGhost : एक परीक्षण जोड़ा (https://github.com/rust-lang/rust/pull/70539)
• @वर्कर :
  
  
  
  • बेहतर सुंदर-मुद्रण (https://github.com/rust-lang/rust/pull/67909, https://github.com/rust-lang/rust/pull/68111)
  
  
  • विभिन्न त्रुटियों को ठीक किया गया (https://github.com/rust-lang/rust/pull/67906, https://github.com/rust-lang/rust/pull/68388, https://github.com/rust- लैंग/रस्ट/पुल/68434)
  
  
  • बेहतर निदान (https://github.com/rust-lang/rust/pull/70845)
  
  
  • जोड़े गए परीक्षण (https://github.com/rust-lang/rust/pull/68312, https://github.com/rust-lang/rust/pull/70939)
  
  

जबकि कॉन्स्ट जेनरिक पहले ही एक लंबा सफर तय कर चुका है, फिर भी बग और तेज किनारे हैं । यदि आप किसी भी शेष मुद्दे से निपटने में रुचि रखते हैं, तो मुझे बेझिझक पिंग करें, @eddyb मुद्दे पर, या ज़ुलिप पर, आरंभ करने के लिए संकेत के लिए। शुक्रिया!