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 倉(cāng)庫(kù)中的提案 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ù)語(yǔ)#447、泛型總覽#524與泛型細(xì)節(jié)第一部分#553之后的系列提案之一最終內(nèi)容落地于 docs/design/generics/details.md。讀完本文你將理解這些機(jī)制要解決什么問(wèn)題、為什么采用當(dāng)前的語(yǔ)法決策、以及它們的實(shí)現(xiàn)與編譯期查證邏輯在倉(cāng)庫(kù)源碼中如何體現(xiàn)。提案背景與定位Carbon 希望提供高質(zhì)量泛型能力目標(biāo)見 泛型目標(biāo)提案但這一特性過(guò)于龐大無(wú)法在一次提案中全部落地因此被拆分為一系列提案逐步細(xì)化#24: Generics goals——確立泛型特性目標(biāo)#447: Generics terminology——統(tǒng)一泛型術(shù)語(yǔ)#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è)主題主題核心問(wèn)題關(guān)鍵語(yǔ)法機(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ù)語(yǔ)文檔。關(guān)聯(lián)常量與關(guān)聯(lián)類型語(yǔ)法決策使用let聲明編譯期常量關(guān)聯(lián)常量associated constants指的是接口中除方法之外的其他成員它們由接口的實(shí)現(xiàn)者提供具體值。提案指出問(wè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本身無(wú)需修改當(dāng)約束收緊時(shí)只需修改不滿足新約束的實(shí)現(xiàn)再修改接口本身。備選方案一省略類型聲明曾考慮在impl中省略類型、始終使用接口中聲明的類型class DynamicArray(T:! Type) { ... impl as Stack { let ElementType T; // 無(wú)類型標(biāo)注 fn Pushaddr me: Self*; ... } }該方案在接口約束變化時(shí)改動(dòng)更少但無(wú)法增量地強(qiáng)化約束。最終選擇顯式把約束寫進(jìn)實(shí)現(xiàn)雖然在某些情況下會(huì)產(chǎn)生更多噪音例如新增約束時(shí)即使所有實(shí)現(xiàn)已滿足也要逐一更新但好處是獲得更多工具來(lái)增量式地推進(jìn)接口約束的變更因此被采納提案也明確表示若實(shí)踐表明這是糟糕的權(quán)衡應(yīng)當(dāng)重新評(píng)估。備選方案二從方法簽名推斷關(guān)聯(lián)類型Swift 方案被拒絕Swift 允許在方法簽名可推導(dǎo)時(shí)省略關(guān)聯(lián)類型的值見 Swift 官方文檔對(duì)關(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í)無(wú)需修改所有實(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 { // 無(wú)法確定 T 是 DynamicArray(Int) 還是 // DynamicArray(DynamicArray(Int)). fn Fme: Self), y: DynamicArray(Int)) { ... } } }Swift 曾因關(guān)聯(lián)類型推斷是唯一需要全局類型推斷的特性而考慮移除后來(lái)決定保留。Carbon 認(rèn)為它帶來(lái)推斷復(fù)雜度且并非必要因此僅做了簡(jiǎn)短討論便未采納。落地現(xiàn)狀where子句與關(guān)聯(lián)常量需要說(shuō)明的是語(yǔ)法在設(shè)計(jì)演進(jìn)中有所調(diào)整。當(dāng)前 details.md 中關(guān)聯(lián)常量使用let聲明、通過(guò)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)方通過(guò)where .N 2等語(yǔ)法為關(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連接。這些值可作為類型成員直接訪問(wèn)如Point2D.N 2也可在 checked-generic 函數(shù)體內(nèi)使用如PointT.N作為數(shù)組長(zhǎng)度。關(guān)聯(lián)常量也可以是函數(shù)稱為關(guān)聯(lián)函數(shù)associated functions通過(guò)接口內(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ù)的聲明語(yǔ)法保持一致見 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)而變化。倉(cāng)庫(kù)中典型的例子是棧接口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 的說(shuō)明看在 checked-generic 函數(shù)內(nèi)部StackType.ElementType是一個(gè) archetype原型類型其 API 由接口中的聲明決定而在泛型之外關(guān)聯(lián) facet 由 impl 查找得到具體值——例如對(duì)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ò)誤: 無(wú)法推導(dǎo)接口參數(shù) T。 fn BrokenPeekAtTopOfStackParameterized [T: type, StackType: StackParameterized(T)] (s: StackType*) - T { ... }原因在于編譯器無(wú)法確定傳入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ù)化接口對(duì)運(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)樗鼈冊(cè)诰幾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)同一類型對(duì)相同參數(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 對(duì)接口 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ù)其語(yǔ)義與接口參數(shù)一致詳見 details.md 的 Parameterized named constraints 小節(jié)。Adapter適配器為類型切換接口視圖為什么需要 adapter由于接口對(duì)同一類型最多實(shí)現(xiàn)一次且實(shí)現(xiàn)位置受到限制即孤兒規(guī)則的約束見 details.md用戶需要一種切換值的類型以訪問(wèn)不同接口實(shí)現(xiàn)的手段。Carbon 因此提供 adapter創(chuàng)建與既有類型兼容、但 API尤其接口實(shí)現(xiàn)集合不同的新類型。倉(cāng)庫(kù)的典型示例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 ... ...語(yǔ)法直接復(fù)用。adapter 的完整定義可添加哪些聲明、兼容規(guī)則、成員訪問(wèn)、類型間轉(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是兼容類型但對(duì)應(yīng)的HashMap類型不兼容——因?yàn)?HashMap 的不變量依賴哈希函數(shù)保持不變。擴(kuò)展 adapterextend adapt多數(shù)情況下 adapter 希望保留原類型的大部分 API最常見的是新增或替換某個(gè)接口實(shí)現(xiàn)。用extend前綴修飾adapt即可從原類型既有 API 出發(fā)extend同時(shí)擴(kuò)展成員訪問(wèn)與 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ā)的庫(kù)兩個(gè)包CompareLib定義CompareLib.Comparable接口與 checked-generic 算法CompareLib.Sort與SongLib定義類型SongLib.Song彼此無(wú)依賴因此任何一方都不會(huì)為對(duì)方定義實(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è)接口再通過(guò)impl as ... ...語(yǔ)法把它拉進(jìn)來(lái)復(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)庫(kù)公開某個(gè)類型、但只想把該類型實(shí)現(xiàn)了某接口作為內(nèi)部實(shí)現(xiàn)細(xì)節(jié)時(shí)可為該類型創(chuàng)建私有 adapter 并在其上實(shí)現(xiàn)接口成員方法通過(guò)把self轉(zhuǎn)換到 adapter 類型來(lái)使用該私有實(shí)現(xiàn)// 公開位于 API 文件 class Complex64 { // ... fn CloserToOrigin(self, them: Self) - bool; } // 私有 class ByReal { extend adapt Complex64; // 復(fù)數(shù)通常不可比較但這個(gè)比較函數(shù)對(duì)某些方法實(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)用例四便捷訪問(wèn)接口名字如果函數(shù)要調(diào)用某接口的多個(gè)函數(shù)而類型并未extend該接口的實(shí)現(xiàn)每次都要使用限定成員訪問(wè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é)文檔還提示也可以通過(guò)局部 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 的對(duì)象表示object representation就是被適配類型的對(duì)象表示toolchain/check/convert.cpp 在類型轉(zhuǎn)換邏輯中處理 base 與 adapt 關(guān)系包括 tuple/struct 的逐部分轉(zhuǎn)換以及沿 adapter 鏈走到被適配類型的轉(zhuǎn)換路徑。這印證了adapter 是對(duì)象表示相同、接口視圖不同的語(yǔ)義且相關(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)。為保留對(duì)這類筆誤的報(bào)錯(cuò)能力該方案被否決。可推導(dǎo)接口參數(shù)被否決及其與一致性coherence的關(guān)系曾考慮區(qū)分兩種接口參數(shù)multi 參數(shù)即現(xiàn)在的參數(shù)化接口參數(shù)與deducible可推導(dǎo)類型參數(shù)。后者只允許一個(gè)類型對(duì)接口有一種實(shí)現(xiàn)可像關(guān)聯(lián)類型一樣被推斷fn PeekAtTopOfStack[ElementType:! Type, StackType:! Stack(ElementType)] (s: StackType*) - ElementType { ... }提案給出了系統(tǒng)的否決理由只有一種參數(shù)使語(yǔ)言更簡(jiǎn)單multi 參數(shù)表達(dá)了確實(shí)需要的東西而可推導(dǎo)參數(shù)總能改寫為關(guān)聯(lián)類型每個(gè)接口 × 參數(shù)組合一種實(shí)現(xiàn)與其他參數(shù)化構(gòu)造如Foo(A)與Foo(B)是兩個(gè)不同且無(wú)關(guān)的類型更一致難以給出何時(shí)用關(guān)聯(lián)類型、何時(shí)用可推導(dǎo)參數(shù)的清晰指引結(jié)構(gòu)接口中的可推導(dǎo)參數(shù)需要額外規(guī)則確保無(wú)歧義推導(dǎo)。最關(guān)鍵的是可推導(dǎo)接口參數(shù)會(huì)復(fù)雜化 impl 的查找規(guī)則并可能破壞一致性coherence見 docs/design/generics/goals.md。提案用一組包/庫(kù)的例子說(shuō)明問(wèn)題假設(shè)X庫(kù)定義了接口I(T)與類型A而Y庫(kù)為X.I(Y.T1)實(shí)現(xiàn)X.A、Z庫(kù)為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 對(duì) 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 對(duì) 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 對(duì)某個(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ā)對(duì)接口X.I(T)的查找而Y.T1與Z.T2兩個(gè)庫(kù)中存在針對(duì)不同T的實(shí)現(xiàn)由此帶來(lái)一系列問(wèn)題只導(dǎo)入你使用的難以度量Y、Z除了import語(yǔ)句外從未被提及卻影響著行為F(a)的解釋取決于導(dǎo)入組合都不導(dǎo)入時(shí)報(bào)錯(cuò)都導(dǎo)入時(shí)產(chǎn)生歧義只導(dǎo)入一個(gè)時(shí)執(zhí)行的代碼完全不同無(wú)法強(qiáng)制每接口一種實(shí)現(xiàn)規(guī)則來(lái)消除歧義。本質(zhì)上如果允許接口參數(shù)被推導(dǎo)就無(wú)法保證導(dǎo)入那些定義了接口參數(shù)所用類型的庫(kù)。接口實(shí)現(xiàn)是 Carbon 中唯一允許開放擴(kuò)展open extension的語(yǔ)言構(gòu)造是解決表達(dá)式問(wèn)題的關(guān)鍵但必須限制哪些庫(kù)能為類型實(shí)現(xiàn)接口以保證使用時(shí)必然能看到實(shí)現(xiàn)——這正是本提案沒有采用可推導(dǎo)接口參數(shù)的根本原因。只保留關(guān)聯(lián)類型、不要接口參數(shù)Swift 路線被否決Swift 只使用關(guān)聯(lián)類型但這樣無(wú)法用接口表達(dá)運(yùn)算符重載——例如向量既應(yīng)能與向量相加、也應(yīng)能與點(diǎn)相加。因此 Carbon 跟隨 Rust在關(guān)聯(lián)類型之外還提供 trait接口參數(shù)并以此定義運(yùn)算符行為。與其他語(yǔ)言的橫向?qū)Ρ刃〗Y(jié)機(jī)制CarbonRustSwift關(guān)聯(lián)類型關(guān)聯(lián)常量 / 關(guān)聯(lián) facetletwhereassociated typesassociated types接口參數(shù)參數(shù)化接口checkedgeneric traits無(wú)只有關(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ù)語(yǔ)中 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賦值等語(yǔ)法選擇提案記錄了完整的設(shè)計(jì)權(quán)衡過(guò)程尤其是對(duì) Swift 關(guān)聯(lián)類型推斷與可推導(dǎo)接口參數(shù)的否決以及對(duì)一致性/coherence 的守護(hù)。當(dāng)前設(shè)計(jì)文檔中的語(yǔ)法在細(xì)節(jié)上有進(jìn)一步演進(jìn)如關(guān)聯(lián)常量通過(guò)where子句賦值但核心概念與取舍一脈相承且 adapter 的合法性檢查已在 toolchain/check/class.cpp 等編譯器源碼中落地。繼續(xù)深入可參考以下倉(cāng)庫(kù)文檔設(shè)計(jì)細(xì)節(jié)全文docs/design/generics/details.md含 adapting types、associated constants、associated facets、parameterized interfaces 各節(jié)高層總覽docs/design/generics/overview.md術(shù)語(yǔ)澄清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），僅供參考