Carbon 泛型細(xì)節(jié)二Adapter、關(guān)聯(lián)類型與參數(shù)化接口的設(shè)計(jì)與演進(jìn)【免費(fèi)下載鏈接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang導(dǎo)讀本文基于 Carbon Language 倉庫中的提案 p000731-generics-details-2-adapters-associated-types-parameterized-interfaces.md系統(tǒng)講解 Carbon 泛型設(shè)計(jì)中三個(gè)核心機(jī)制適配器adapter、關(guān)聯(lián)常量與關(guān)聯(lián)類型associated constants / associated types、以及參數(shù)化接口parameterized interfaces。這是繼泛型目標(biāo)#24、泛型術(shù)語#447、泛型總覽#524與泛型細(xì)節(jié)第一部分#553之后的系列提案之一最終內(nèi)容落地于 docs/design/generics/details.md。讀完本文你將理解這些機(jī)制要解決什么問題、為什么采用當(dāng)前的語法決策、以及它們的實(shí)現(xiàn)與編譯期查證邏輯在倉庫源碼中如何體現(xiàn)。提案背景與定位Carbon 希望提供高質(zhì)量泛型能力目標(biāo)見 泛型目標(biāo)提案但這一特性過于龐大無法在一次提案中全部落地因此被拆分為一系列提案逐步細(xì)化#24: Generics goals——確立泛型特性目標(biāo)#447: Generics terminology——統(tǒng)一泛型術(shù)語#524: Generics overview——給出泛型特性的高層描述與文檔導(dǎo)航#553: Generics details part 1——泛型細(xì)節(jié)第一部分本提案#731——繼續(xù)細(xì)化adapter、關(guān)聯(lián)類型與其他常量、參數(shù)化接口三塊內(nèi)容后續(xù)還有 泛型細(xì)節(jié) 3constraints 等繼續(xù)推進(jìn)。本提案的內(nèi)容最初提取自一個(gè)更大的 Generics combined draft proposal具體做法是向 docs/design/generics/details.md 這個(gè)設(shè)計(jì)文檔新增多個(gè)章節(jié)。該文檔當(dāng)前已包含完整的 Adapting types、Associated constants、Associated facets 與 Parameterized interfaces 章節(jié)正是本提案結(jié)論的延續(xù)與落地。三大核心主題概述提案將泛型細(xì)節(jié)的第二批內(nèi)容劃分為三個(gè)主題主題核心問題關(guān)鍵語法機(jī)制適配器adapters同一類型只能實(shí)現(xiàn)接口一次且實(shí)現(xiàn)位置受限如何為值切換接口視圖adapt關(guān)鍵字、extend adapt、impl as ... ...關(guān)聯(lián)常量 / 關(guān)聯(lián)類型接口簽名中的類型如何隨實(shí)現(xiàn)變化接口內(nèi)let常量、where子句賦值參數(shù)化接口如何表達(dá)一族相關(guān)接口允許同一類型多次實(shí)現(xiàn)接口名后參數(shù)列表如Stack(ElementType: type)這三個(gè)機(jī)制共同服務(wù)于一個(gè)目標(biāo)讓checked generics的函數(shù)簽名能夠表達(dá)任意實(shí)現(xiàn)了某接口的類型而不必寫出具體類型同時(shí)保持編譯期可查證詳見 泛型術(shù)語文檔。關(guān)聯(lián)常量與關(guān)聯(lián)類型語法決策使用let聲明編譯期常量關(guān)聯(lián)常量associated constants指的是接口中除方法之外的其他成員它們由接口的實(shí)現(xiàn)者提供具體值。提案指出問題 #739: Associated type syntax 的 let 常量部分保持一致interface Stack { let ElementType:! Type; fn Pushaddr me: Self*; ... } class DynamicArray(T:! Type) { ... impl as Stack { let ElementType:! Type T; fn Pushaddr me: Self*; ... } }這里ElementType就是典型的關(guān)聯(lián)類型接口聲明它存在具體類型如DynamicArray(T)在實(shí)現(xiàn)Stack時(shí)把它綁定為T。用auto自動(dòng)推導(dǎo)類型如果不想手寫約束可以把類型位置換成auto由編譯器根據(jù)右側(cè)的值自動(dòng)確定class DynamicArray(T:! Type) { ... impl as Stack { let ElementType:! auto T; fn Pushaddr me: Self*; ... } }這種寫法的價(jià)值在于接口約束演化時(shí)減少改動(dòng)當(dāng)接口的約束被放寬或收緊時(shí)只要右側(cè)的值仍滿足新約束impl本身無需修改當(dāng)約束收緊時(shí)只需修改不滿足新約束的實(shí)現(xiàn)再修改接口本身。備選方案一省略類型聲明曾考慮在impl中省略類型、始終使用接口中聲明的類型class DynamicArray(T:! Type) { ... impl as Stack { let ElementType T; // 無類型標(biāo)注 fn Pushaddr me: Self*; ... } }該方案在接口約束變化時(shí)改動(dòng)更少但無法增量地強(qiáng)化約束。最終選擇顯式把約束寫進(jìn)實(shí)現(xiàn)雖然在某些情況下會(huì)產(chǎn)生更多噪音例如新增約束時(shí)即使所有實(shí)現(xiàn)已滿足也要逐一更新但好處是獲得更多工具來增量式地推進(jìn)接口約束的變更因此被采納提案也明確表示若實(shí)踐表明這是糟糕的權(quán)衡應(yīng)當(dāng)重新評估。備選方案二從方法簽名推斷關(guān)聯(lián)類型Swift 方案被拒絕Swift 允許在方法簽名可推導(dǎo)時(shí)省略關(guān)聯(lián)類型的值見 Swift 官方文檔對關(guān)聯(lián)類型的描述。例如上面的例子只需從上下文推斷ElementType Tclass DynamicArray(T:! Type) { ... impl as Stack { // 不需要寫: let ElementType:! Type T; fn Pushaddr me: Self*; ... } }好處是接口新增關(guān)聯(lián)類型時(shí)無需修改所有實(shí)現(xiàn)。但提案指出這在存在帶默認(rèn)實(shí)現(xiàn)的方法重載時(shí)會(huì)復(fù)雜化例如interface Has2OverloadsWithDefaults { let T:! StackAssociatedType; fn Fme: Self, y: T) { ... } fn Fme: Self { ... } } class S { impl as Has2OverloadsWithDefaults { // 無法確定 T 是 DynamicArray(Int) 還是 // DynamicArray(DynamicArray(Int)). fn Fme: Self), y: DynamicArray(Int)) { ... } } }Swift 曾因關(guān)聯(lián)類型推斷是唯一需要全局類型推斷的特性而考慮移除后來決定保留。Carbon 認(rèn)為它帶來推斷復(fù)雜度且并非必要因此僅做了簡短討論便未采納。落地現(xiàn)狀where子句與關(guān)聯(lián)常量需要說明的是語法在設(shè)計(jì)演進(jìn)中有所調(diào)整。當(dāng)前 details.md 中關(guān)聯(lián)常量使用let聲明、通過where子句賦值。例如固定維度的點(diǎn)類型interface NSpacePoint { let N: i32; // 以下方法要求: 0 i N。 fn Get(ref self, i: i32) - f64; fn Set(ref self, i: i32, value: f64); // 關(guān)聯(lián)常量可用于簽名: fn SetAll(ref self, value: Array(f64, N)); }實(shí)現(xiàn)方通過where .N 2等語法為關(guān)聯(lián)常量賦值class Point2D { extend impl as NSpacePoint where .N 2 { fn Get(ref self, i: i32) - f64 { ... } fn Set(ref self, i: i32, value: f64) { ... } fn SetAll(ref self, value: Array(f64, 2)) { ... } } }關(guān)聯(lián)常量還有兩條硬性約束不能為final關(guān)聯(lián)常量指定值沒有默認(rèn)值的關(guān)聯(lián)常量每個(gè)實(shí)現(xiàn)都必須指定。多個(gè)賦值可以用and連接。這些值可作為類型成員直接訪問如Point2D.N 2也可在 checked-generic 函數(shù)體內(nèi)使用如PointT.N作為數(shù)組長度。關(guān)聯(lián)常量也可以是函數(shù)稱為關(guān)聯(lián)函數(shù)associated functions通過接口內(nèi)的fn聲明例如反序列化接口interface DeserializeFromString { fn Deserialize(serialized: String) - Self; } class MySerializableType { var i: i32; extend impl as DeserializeFromString { fn Deserialize(serialized: String) - Self { return {.i StringToInt(serialized)}; } } } var x: MySerializableType MySerializableType.Deserialize(3);這里沒有使用用let聲明函數(shù)類型常量的寫法而是直接用fn以與類成員函數(shù)的聲明語法保持一致見 classes.md。關(guān)聯(lián) Facet讓方法簽名隨實(shí)現(xiàn)變化如果關(guān)聯(lián)常量的類型本身是 facet 類型就得到關(guān)聯(lián) facetassociated facets。它們的價(jià)值在于可出現(xiàn)在關(guān)聯(lián)方法或函數(shù)的簽名中使方法簽名隨實(shí)現(xiàn)而變化。倉庫中典型的例子是棧接口interface StackAssociatedFacet { let ElementType: type; fn Push(ref self, value: ElementType); fn Pop(ref self) - ElementType; fn IsEmpty(ref self) - bool; }DynamicArray(T)實(shí)現(xiàn)它時(shí)把ElementType綁定到Tclass DynamicArray(T: type) { ... extend impl as StackAssociatedFacet where .ElementType T { fn Push(ref self, value: ElementType) { self.Insert(self.End(), value); } fn Pop(ref self) - ElementType { var pos: IteratorType self.End(); Assert(pos ! self.Begin()); --pos; returned var ret: ElementType *pos; self.Remove(pos); return var; } fn IsEmpty(ref self) - bool { return self.Begin() self.End(); } } }有了這個(gè)接口就能寫出不依賴具體類型的 checked-generic 函數(shù)fn PeekAtTopOfStackStackType: StackAssociatedFacet - StackType.ElementType { var top: StackType.ElementType s-Pop(); s-Push(top); return top; }從 details.md 的說明看在 checked-generic 函數(shù)內(nèi)部StackType.ElementType是一個(gè) archetype原型類型其 API 由接口中的聲明決定而在泛型之外關(guān)聯(lián) facet 由 impl 查找得到具體值——例如對DynamicArray(i32)StackType.ElementType就是i32。這支撐了 泛型目標(biāo)文檔 中泛型函數(shù)可替代普通函數(shù)而不改變調(diào)用者所見返回類型的目標(biāo)。關(guān)聯(lián) facet 還可以用**成員類型member type**實(shí)現(xiàn)。此外 terminology.md 用輸入/輸出模型給出了清晰的區(qū)分接口參數(shù)是輸入必須先指定才能確定impl關(guān)聯(lián)常量是輸出由impl決定、不參與impl選擇。例如容器的迭代器類型由容器自身決定正適合作為關(guān)聯(lián)常量。參數(shù)化接口一族接口與多重實(shí)現(xiàn)基本形態(tài)與每種參數(shù)一種實(shí)現(xiàn)關(guān)聯(lián)常量不改變一個(gè)類型最多實(shí)現(xiàn)一個(gè)接口一次的事實(shí)。若想表達(dá)一族相關(guān)接口同一類型可為不同參數(shù)值提供多個(gè)實(shí)現(xiàn)就需要參數(shù)化接口寫法是接口名后跟參數(shù)列表interface StackParameterized(ElementType: type) { fn Push(ref self, value: ElementType); fn Pop(ref self) - ElementType; fn IsEmpty(ref self) - bool; }此時(shí)StackParameterized(Fruit)與StackParameterized(Veggie)被視為不同的接口、擁有獨(dú)立的實(shí)現(xiàn)。一個(gè)類型可以同時(shí)實(shí)現(xiàn)它們class Produce { var fruit: DynamicArray(Fruit); var veggie: DynamicArray(Veggie); extend impl as StackParameterized(Fruit) { fn Push(ref self, value: Fruit) { self.fruit.Push(value); } fn Pop(ref self) - Fruit { return self.fruit.Pop(); } fn IsEmpty(ref self) - bool { return self.fruit.IsEmpty(); } } extend impl as StackParameterized(Veggie) { fn Push(ref self, value: Veggie) { self.veggie.Push(value); } fn Pop(ref self) - Veggie { return self.veggie.Pop(); } fn IsEmpty(ref self) - bool { return self.veggie.IsEmpty(); } } }接口參數(shù)不可推導(dǎo)與接口中的關(guān)聯(lián)常量、類型參數(shù)不同接口參數(shù)不能被推導(dǎo)。改寫上面PeekAtTopOfStack的例子會(huì)直接產(chǎn)生編譯錯(cuò)誤// ? 錯(cuò)誤: 無法推導(dǎo)接口參數(shù) T。 fn BrokenPeekAtTopOfStackParameterized [T: type, StackType: StackParameterized(T)] (s: StackType*) - T { ... }原因在于編譯器無法確定傳入Produce*時(shí)T應(yīng)該是Fruit還是Veggie。解決辦法有二要么把T替換成具體類型fn PeekAtTopOfFruitStack [StackType: StackParameterized(Fruit)] (s: StackType*) - T { ... } var produce: Produce ...; var top_fruit: Fruit PeekAtTopOfFruitStack(produce);要么顯式傳遞T配合where約束詳見 details.md 中Another type implements parameterized interface小節(jié)fn PeekAtTopOfStackParameterizedImpl (generic T: type, generic StackType: StackParameterized(T), s: StackType*) - T { ... } fn PeekAtTopOfStackParameterized[StackType: type] (s: StackType*, generic T: type where StackType impls StackParameterized(T)) - T { return PeekAtTopOfStackParameterizedImpl(T, StackType, s); }運(yùn)算符重載與多重實(shí)現(xiàn)參數(shù)化接口對運(yùn)算符重載尤其有用EqWith(T)、OrderedWith(T)這類接口允許一個(gè)類型與多個(gè)其他類型比較。例如interface EqWith(T: type) { fn Equal(self, rhs: T) - bool; ... } class Complex { var real: f64; var imag: f64; // 只要參數(shù)不同可以多次實(shí)現(xiàn)同一接口 extend impl as EqWith(f64) { ... } // 等價(jià)于: impl as EqWith(Complex) { ... } extend impl as EqWith(Self) { ... } }接口參數(shù)默認(rèn)都是 checked 參數(shù)因?yàn)樗鼈冊诰幾g期就必須解析且允許傳入 symbolic 或 template 值。接口參數(shù)也不要求一定是 facet 類型只是絕大多數(shù)情況如此——例如把元組成員讀取操作建模為以index為參數(shù)的接口interface ReadTupleMember(index: u32) { let T: type; // 返回 self[index] fn Get(self) - T; }同一參數(shù)值不可實(shí)現(xiàn)兩次Map 與 Bijection 的教訓(xùn)當(dāng)同一類型對相同參數(shù)組合實(shí)現(xiàn)了兩次同一接口時(shí)會(huì)產(chǎn)生編譯錯(cuò)誤interface Map(FromType: type, ToType: type) { fn Map(ref self, needle: FromType) - Optional(ToType); } class Bijection(FromType: type, ToType: type) { extend impl as Map(FromType, ToType) { ... } extend impl as Map(ToType, FromType) { ... } } // ? 錯(cuò)誤: Bijection 對接口 Map(String, String) 有兩個(gè)不同的 impl 定義 var oops: Bijection(String, String) ...;當(dāng)FromType ToType時(shí)兩個(gè) impl 沖突。文檔給出的修復(fù)方案正是使用適配器容納反向查找的 implclass Bijection(FromType: type, ToType: type) { extend impl as Map(FromType, ToType) { ... } } class ReverseLookup(FromType: type, ToType: type) { adapt Bijection(FromType, ToType); extend impl as Map(ToType, FromType) { ... } }參數(shù)化命名約束不僅接口可以參數(shù)化命名約束named constraints也支持參數(shù)其語義與接口參數(shù)一致詳見 details.md 的 Parameterized named constraints 小節(jié)。Adapter適配器為類型切換接口視圖為什么需要 adapter由于接口對同一類型最多實(shí)現(xiàn)一次且實(shí)現(xiàn)位置受到限制即孤兒規(guī)則的約束見 details.md用戶需要一種切換值的類型以訪問不同接口實(shí)現(xiàn)的手段。Carbon 因此提供 adapter創(chuàng)建與既有類型兼容、但 API尤其接口實(shí)現(xiàn)集合不同的新類型。倉庫的典型示例interface Printable { fn Print(self); } interface Ordered { fn Less(self, rhs: Self) - bool; } class Song { extend impl as Printable { fn Print(self) { ... } } } class SongByTitle { adapt Song; extend impl as Ordered { fn Less(self, rhs: Self) - bool { ... } } } class FormattedSong { adapt Song; extend impl as Printable { fn Print(self) { ... } } } class FormattedSongByTitle { adapt Song; extend impl as Printable FormattedSong; extend impl as Ordered SongByTitle; }可以看到 adapter 支持三種典型用法為原類型補(bǔ)充新接口實(shí)現(xiàn)SongByTitle、提供同一接口的不同實(shí)現(xiàn)FormattedSong、以及從其他兼容類型組合復(fù)用實(shí)現(xiàn)FormattedSongByTitle用impl as ... ...語法直接復(fù)用。adapter 的完整定義可添加哪些聲明、兼容規(guī)則、成員訪問、類型間轉(zhuǎn)換見 classes.md 的 adapters 章節(jié)。Adapter 兼容性HashMap 的例子考慮一個(gè)帶 facet 參數(shù)的類型如哈希表interface Hashable { ... } class HashMap(KeyT: Hashable, ValueT: type) { fn Find(self, key: KeyT) - Optional(ValueT); // ... }由于KeyT、ValueT是 checked 參數(shù)Find只能使用參數(shù)類型被聲明要求的那些能力?；谶@一點(diǎn)可以判定兩個(gè) adapter 之間何時(shí)允許轉(zhuǎn)換。設(shè)有兩個(gè)Song的 adapterclass PlayableSong { adapt Song; extend impl as Hashable Song; // 復(fù)用 Song 的 Hashable 實(shí)現(xiàn) extend impl as Media { ... } } class SongHashedByTitle { adapt Song; extend impl as Hashable { ... } // 不同的 Hashable 實(shí)現(xiàn) }Song與PlayableSong不僅數(shù)據(jù)表示相同Hashable的實(shí)現(xiàn)也相同因此HashMap(Song, i32)與HashMap(PlayableSong, i32)之間可以顯式轉(zhuǎn)換而SongHashedByTitle的哈希實(shí)現(xiàn)不同雖然Song與SongHashedByTitle是兼容類型但對應(yīng)的HashMap類型不兼容——因?yàn)?HashMap 的不變量依賴哈希函數(shù)保持不變。擴(kuò)展 adapterextend adapt多數(shù)情況下 adapter 希望保留原類型的大部分 API最常見的是新增或替換某個(gè)接口實(shí)現(xiàn)。用extend前綴修飾adapt即可從原類型既有 API 出發(fā)extend同時(shí)擴(kuò)展成員訪問與 impl 查找見 member_access.mdclass SongByArtist { extend adapt Song; // 新增一個(gè)接口實(shí)現(xiàn) extend impl as Ordered { ... } // 用另一種實(shí)現(xiàn)替換既有實(shí)現(xiàn) extend impl as Hashable { ... } }結(jié)果SongByArtist實(shí)現(xiàn)了OrderedSong沒有、實(shí)現(xiàn)了Hashable但不同于Song、繼承了Song的Printable。其規(guī)則是查找SongByArtist是否實(shí)現(xiàn)接口I時(shí)若未找到編譯器會(huì)繼續(xù)查看Song是否實(shí)現(xiàn)I找到則盡可能復(fù)用——只要接口函數(shù)簽名中引用Self的類型都能相應(yīng)替換轉(zhuǎn)換成功。需要注意class B { extend base: A; }的類擴(kuò)展中基類不能是 final但class B { extend adapt A; }在A是 final 類時(shí)也允許。與普通adapt一致B到A沒有隱式轉(zhuǎn)換。當(dāng)接口間出現(xiàn)名字沖突時(shí)可以去掉extend實(shí)現(xiàn)接口再用alias單獨(dú)引入或重命名所需名字class SongRenderToPrintDriver { extend adapt Song; // 新增一個(gè) Print() 成員函數(shù) fn Print(self) { ... } // 與新的 Print 避免名字沖突: // 以非 extend 方式實(shí)現(xiàn) Printable impl as Printable Song; // 把 Printable.Print 以 PrintToScreen 名字暴露 alias PrintToScreen Printable.Print; }實(shí)戰(zhàn)用例一組合獨(dú)立開發(fā)的庫兩個(gè)包CompareLib定義CompareLib.Comparable接口與 checked-generic 算法CompareLib.Sort與SongLib定義類型SongLib.Song彼此無依賴因此任何一方都不會(huì)為對方定義實(shí)現(xiàn)。用戶可定義一個(gè) adapter 為SongLib.Song提供CompareLib.Comparable實(shí)現(xiàn)import CompareLib; import SongLib; class Song { extend adapt SongLib.Song; extend impl as CompareLib.Comparable { ... } } // 或者不把 CompareLib.Comparable 的名字混入 Song 的 API: class Song { extend adapt SongLib.Song; } impl Song as CompareLib.Comparable { ... }調(diào)用時(shí)既可以把SongLib.Song顯式轉(zhuǎn)換為Song也可以直接使用Song值var lib_song: SongLib.Song ...; CompareLib.Sort((lib_song as Song,)); var song: Song ...; CompareLib.Sort((song,));實(shí)戰(zhàn)用例二為其他類型提供可復(fù)用實(shí)現(xiàn)可以定義一個(gè)以被適配類型為參數(shù)的 adapter實(shí)現(xiàn)某個(gè)接口再通過impl as ... ...語法把它拉進(jìn)來復(fù)用。例如為所有實(shí)現(xiàn)了Difference接口的類型提供Comparableinterface Comparable { fn Less(self, rhs: Self) - bool; } interface Difference { fn Sub(self, rhs: Self) - i32; } class ComparableFromDifference(T: Difference) { adapt T; extend impl as Comparable { fn Less(self, rhs: Self) - bool { return (self as T).Sub(rhs) 0; } } } class IntWrapper { var x: i32; impl as Difference { fn Sub(self, rhs: Self) - i32 { return left.x - right.x; } } impl as Comparable ComparableFromDifference(IntWrapper); }實(shí)戰(zhàn)用例三私有實(shí)現(xiàn)Private impl當(dāng)庫公開某個(gè)類型、但只想把該類型實(shí)現(xiàn)了某接口作為內(nèi)部實(shí)現(xiàn)細(xì)節(jié)時(shí)可為該類型創(chuàng)建私有 adapter 并在其上實(shí)現(xiàn)接口成員方法通過把self轉(zhuǎn)換到 adapter 類型來使用該私有實(shí)現(xiàn)// 公開位于 API 文件 class Complex64 { // ... fn CloserToOrigin(self, them: Self) - bool; } // 私有 class ByReal { extend adapt Complex64; // 復(fù)數(shù)通常不可比較但這個(gè)比較函數(shù)對某些方法實(shí)現(xiàn)很有用。 extend impl as Comparable { fn Less(self, that: Self) - bool { return self.Real() that.Real(); } } } fn Complex64.CloserToOrigin(self, them: Self) - bool { var self_mag: ByReal self * self.Conj() as ByReal; var them_mag: ByReal them * them.Conj() as ByReal; return self_mag.Less(them_mag); }實(shí)戰(zhàn)用例四便捷訪問接口名字如果函數(shù)要調(diào)用某接口的多個(gè)函數(shù)而類型并未extend該接口的實(shí)現(xiàn)每次都要使用限定成員訪問會(huì)比較啰嗦。adapter 可以把實(shí)現(xiàn)了該接口變成類型本身 API 的一部分interface DrawingContext { fn SetPen(self, ...); fn SetFill(self, ...); fn DrawRectangle(self, ...); fn DrawLine(self, ...); ... } impl Window as DrawingContext { ... } class DrawInWindow { adapt Window; extend impl as DrawingContext Window; } fn Render(w: Window) { let d: DrawInWindow w as DrawInWindow; d.SetPen(...); d.SetFill(...); d.DrawRectangle(...); ... }細(xì)節(jié)文檔還提示也可以通過局部 symbolic facet 常量達(dá)到同樣效果let generic DrawInWindow: Draw Window;這屬于另一條路徑。源碼層面的印證adapter 并非紙上設(shè)計(jì)在工具鏈實(shí)現(xiàn)中已有明確落點(diǎn)toolchain/check/class.cpp 負(fù)責(zé)校驗(yàn) adapter 定義的合法性定義了AdaptWithBaseadapter 帶基類、AdaptWithFieldsadapter 帶字段、AdaptWithVirtualadapter 帶虛函數(shù)等診斷錯(cuò)誤同時(shí)規(guī)定 adapter 的對象表示object representation就是被適配類型的對象表示toolchain/check/convert.cpp 在類型轉(zhuǎn)換邏輯中處理 base 與 adapt 關(guān)系包括 tuple/struct 的逐部分轉(zhuǎn)換以及沿 adapter 鏈走到被適配類型的轉(zhuǎn)換路徑。這印證了adapter 是對象表示相同、接口視圖不同的語義且相關(guān)規(guī)則已被編譯器實(shí)現(xiàn)與診斷覆蓋。被否決的備選方案與理由為什么是adapter而不是adaptor兩種拼寫都有依據(jù)但-er拼寫在英文文本和代碼中更常見且 GoF《設(shè)計(jì)模式》一書采用-er拼寫adapter pattern因此最終選定adapter。值模式Value patterns被否決曾考慮允許函數(shù)參數(shù)使用不帶:的值模式以便把T綁定到參數(shù)列表中較后出現(xiàn)的類型fn PeekAtTopOfStackParameterized [T:! Type, StackType:! StackParameterized(T)] (s: StackType*, T) - T { ... }但 Carbon 不希望普遍開放值模式——否則fn F(Int)這類聲明會(huì)被接受而用戶幾乎總是想寫fn F(i: Int)。為保留對這類筆誤的報(bào)錯(cuò)能力該方案被否決?？赏茖?dǎo)接口參數(shù)被否決及其與一致性coherence的關(guān)系曾考慮區(qū)分兩種接口參數(shù)multi 參數(shù)即現(xiàn)在的參數(shù)化接口參數(shù)與deducible可推導(dǎo)類型參數(shù)。后者只允許一個(gè)類型對接口有一種實(shí)現(xiàn)可像關(guān)聯(lián)類型一樣被推斷fn PeekAtTopOfStack[ElementType:! Type, StackType:! Stack(ElementType)] (s: StackType*) - ElementType { ... }提案給出了系統(tǒng)的否決理由只有一種參數(shù)使語言更簡單multi 參數(shù)表達(dá)了確實(shí)需要的東西而可推導(dǎo)參數(shù)總能改寫為關(guān)聯(lián)類型每個(gè)接口 × 參數(shù)組合一種實(shí)現(xiàn)與其他參數(shù)化構(gòu)造如Foo(A)與Foo(B)是兩個(gè)不同且無關(guān)的類型更一致難以給出何時(shí)用關(guān)聯(lián)類型、何時(shí)用可推導(dǎo)參數(shù)的清晰指引結(jié)構(gòu)接口中的可推導(dǎo)參數(shù)需要額外規(guī)則確保無歧義推導(dǎo)。最關(guān)鍵的是可推導(dǎo)接口參數(shù)會(huì)復(fù)雜化 impl 的查找規(guī)則并可能破壞一致性coherence見 docs/design/generics/goals.md。提案用一組包/庫的例子說明問題假設(shè)X庫定義了接口I(T)與類型A而Y庫為X.I(Y.T1)實(shí)現(xiàn)X.A、Z庫為X.I(Z.T2)實(shí)現(xiàn)X.Apackage X library I and A api; interface I(Type:$ T) { ... } struct A { ... }package Y library T1 api; import X library I and A; struct T1 { ... } // 類型 X.A 對 X.I(T) 有實(shí)現(xiàn)其中 T Y.T1。 impl X.I(T1) for X.A { ... }package Z library T2 api; import X library I and A; struct T2 { ... } // 類型 X.A 對 X.I(T) 有實(shí)現(xiàn)其中 T Z.T2。 impl X.I(T2) for X.A { ... }package Main api; import X library I and A; // 考慮如果組合包含下面兩句的不同組合會(huì)怎樣: // import Y library T1; // import Z library T2; // 函數(shù) F 用值 a類型 U調(diào)用其中 U 對某個(gè) T 實(shí)現(xiàn)了接口 X.I(T)。 fn FType:$ T, X.I(T):$ U { ... } fn Main() { var X.A: a X.A.Init(); F(a); }調(diào)用F(a)會(huì)觸發(fā)對接口X.I(T)的查找而Y.T1與Z.T2兩個(gè)庫中存在針對不同T的實(shí)現(xiàn)由此帶來一系列問題只導(dǎo)入你使用的難以度量Y、Z除了import語句外從未被提及卻影響著行為F(a)的解釋取決于導(dǎo)入組合都不導(dǎo)入時(shí)報(bào)錯(cuò)都導(dǎo)入時(shí)產(chǎn)生歧義只導(dǎo)入一個(gè)時(shí)執(zhí)行的代碼完全不同無法強(qiáng)制每接口一種實(shí)現(xiàn)規(guī)則來消除歧義。本質(zhì)上如果允許接口參數(shù)被推導(dǎo)就無法保證導(dǎo)入那些定義了接口參數(shù)所用類型的庫。接口實(shí)現(xiàn)是 Carbon 中唯一允許開放擴(kuò)展open extension的語言構(gòu)造是解決表達(dá)式問題的關(guān)鍵但必須限制哪些庫能為類型實(shí)現(xiàn)接口以保證使用時(shí)必然能看到實(shí)現(xiàn)——這正是本提案沒有采用可推導(dǎo)接口參數(shù)的根本原因。只保留關(guān)聯(lián)類型、不要接口參數(shù)Swift 路線被否決Swift 只使用關(guān)聯(lián)類型但這樣無法用接口表達(dá)運(yùn)算符重載——例如向量既應(yīng)能與向量相加、也應(yīng)能與點(diǎn)相加。因此 Carbon 跟隨 Rust在關(guān)聯(lián)類型之外還提供 trait接口參數(shù)并以此定義運(yùn)算符行為。與其他語言的橫向?qū)Ρ刃〗Y(jié)機(jī)制CarbonRustSwift關(guān)聯(lián)類型關(guān)聯(lián)常量 / 關(guān)聯(lián) facetletwhereassociated typesassociated types接口參數(shù)參數(shù)化接口checkedgeneric traits無只有關(guān)聯(lián)類型關(guān)聯(lián)類型推斷不支持需顯式或auto不支持支持曾考慮移除運(yùn)算符重載建模參數(shù)化接口如EqWith(T)泛型 trait 運(yùn)算符重載運(yùn)算符重載受限于關(guān)聯(lián)類型Rust 術(shù)語中 interface 參數(shù)與關(guān)聯(lián) facet 都叫 type parameters但 Carbon 沿用了 Rust RFC 0195 的區(qū)分接口參數(shù)是輸入決定選擇哪個(gè) impl關(guān)聯(lián)常量是輸出由 impl 決定、不參與選擇。結(jié)論與延伸閱讀本提案確立了 Carbon 泛型細(xì)節(jié)三塊地基adapter 提供類型視圖切換、關(guān)聯(lián)常量讓接口簽名隨實(shí)現(xiàn)變化、參數(shù)化接口表達(dá)一族可多重實(shí)現(xiàn)的接口。圍繞adapter、let :!常量、where賦值等語法選擇提案記錄了完整的設(shè)計(jì)權(quán)衡過程尤其是對 Swift 關(guān)聯(lián)類型推斷與可推導(dǎo)接口參數(shù)的否決以及對一致性/coherence 的守護(hù)。當(dāng)前設(shè)計(jì)文檔中的語法在細(xì)節(jié)上有進(jìn)一步演進(jìn)如關(guān)聯(lián)常量通過where子句賦值但核心概念與取舍一脈相承且 adapter 的合法性檢查已在 toolchain/check/class.cpp 等編譯器源碼中落地。繼續(xù)深入可參考以下倉庫文檔設(shè)計(jì)細(xì)節(jié)全文docs/design/generics/details.md含 adapting types、associated constants、associated facets、parameterized interfaces 各節(jié)高層總覽docs/design/generics/overview.md術(shù)語澄清docs/design/generics/terminology.mdInterface parameters and associated constants一節(jié)泛型目標(biāo)docs/design/generics/goals.md類與 adapter 的完整定義docs/design/classes.md系列后續(xù)泛型細(xì)節(jié) 3constraints【免費(fèi)下載鏈接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考