Túlterhelés feloldási prioritása

Jegyzet

Ez a cikk egy funkcióspecifikáció. A specifikáció a funkció tervezési dokumentumaként szolgál. Tartalmazza a specifikáció javasolt módosításait, valamint a funkció tervezése és fejlesztése során szükséges információkat. Ezeket a cikkeket mindaddig közzéteszik, amíg a javasolt specifikációmódosításokat nem véglegesítik, és be nem építik a jelenlegi ECMA-specifikációba.

A szolgáltatás specifikációja és a befejezett implementáció között eltérések lehetnek. Ezeket a különbségeket a vonatkozó nyelvi tervezési értekezlet (LDM) megjegyzései rögzítik.

A funkcióspektusok C# nyelvi szabványba való bevezetésének folyamatáról a specifikációkcímű cikkben olvashat bővebben.

Bajnoki probléma: https://github.com/dotnet/csharplang/issues/7706

Összefoglalás

Bevezetünk egy új attribútumot, System.Runtime.CompilerServices.OverloadResolutionPriority, amelyet az API-szerzők használhatnak a túlterhelések relatív prioritásának egyetlen típuson belüli módosítására, hogy az API-fogyasztók meghatározott API-kat használjanak, még akkor is, ha ezek az API-k általában nem egyértelműnek minősülnek, vagy egyébként nem a C#túlterhelés-feloldási szabályai választják ki.

Motiváció

Az API-szerzők gyakran találkoznak azzal a problémával, hogy mit kell tenni egy taggal az elavulás után. A visszamenőleges kompatibilitás érdekében sokan megtartják a meglévő tagot, és a ObsoleteAttribute-t állandó hibára állítják be, hogy elkerüljék a problémákat a felhasználóknál, akik a futásidejű bináris frissítéseket végeznek. Ez különösen a beépülő modulrendszerekre vonatkozik, ahol a beépülő modul szerzője nem szabályozza azt a környezetet, amelyben a beépülő modul fut. Előfordulhat, hogy a környezet létrehozója egy régebbi metódust szeretne jelen tartani, de letiltja a hozzáférést az újonnan kifejlesztett kódokhoz. Azonban ObsoleteAttribute önmagában nem elég. A típus vagy tag továbbra is látható a túlterhelés feloldásában, és nemkívánatos túlterhelés-feloldási hibákat okozhat, ha van egy tökéletesen jó alternatíva, de ez az alternatíva vagy nem egyértelmű az elavult taggal, vagy az elavult tag jelenléte miatt a túlterhelés feloldása korán véget ér, anélkül, hogy a jó tagot mérlegelné. Ezért szeretnénk, ha az API-szerzők irányítanák a túlterhelés feloldását a kétértelműség megoldásában, hogy fejleszthessék API-felületeiket, és a felhasználókat a felhasználói élmény veszélyeztetése nélkül irányíthassák a teljesítménnyel rendelkező API-k felé.

Az alaposztálykódtárak (BCL) csapata számos példát mutat be arra, hogy ez hol bizonyulhat hasznosnak. Néhány (hipotetikus) példa:

• Egy olyan Debug.Assert túlterhelés létrehozása, amely CallerArgumentExpression-et használ az érvényesített kifejezés lekérésére, hogy az bekerülhessen az üzenetbe, és így előnyben részesítse a meglévő túlterheléssel szemben.
• string.IndexOf(string, StringComparison = Ordinal) előnyben részesítése string.IndexOf(string). Ezt valószínűleg kompatibilitástörő változásként kellene tárgyalni, de van, aki úgy gondolja, hogy ez a jobb alapértelmezett érték, és nagyobb valószínűséggel az, amit a felhasználó szánt.
• A javaslat és a CallerAssemblyAttribute kombinációja lehetővé tenné, hogy az implicit hívóidentitású metódusok elkerüljék a költséges verembejárásokat. Assembly.Load(AssemblyName) teszi ezt ma, és sokkal hatékonyabb lehet.
• Microsoft.Extensions.Primitives.StringValues implicit konverziót tesz elérhetővé string és string[]. Ez azt jelenti, hogy nem egyértelmű, amikor egy metódusnak adja át, amely params string[] és params ReadOnlySpan<string> túlterhelésű. Ezzel az attribútummal rangsorolható az egyik túlterhelés a kétértelműség elkerülése érdekében.

Részletes tervezés

Túlterhelésfeloldási prioritás

Meghatározunk egy új, overload_resolution_prioritynevű fogalmat, amelyet egy metóduscsoport feloldása során használunk. overload_resolution_priority egy 32 bites egész szám. Minden metódus alapértelmezés szerint 0 overload_resolution_priority rendelkezik, és ez a OverloadResolutionPriorityAttribute metódusra való alkalmazásával módosítható. A C# specifikációjának 12.6.4.1 szakaszt az alábbiak szerint frissítjük (félkövérmódosítása):

A jelölt függvénytagok és az argumentumlista azonosítása után a legjobb függvénytag kiválasztása minden esetben ugyanaz:

• Először is a jelölt függvénytagok halmaza azokra a függvénytagokra csökken, amelyek az adott argumentumlistára vonatkoznak (12.6.4.2.). Ha ez a csökkentett készlet üres, fordítási időhiba lép fel.
• Ezután a jelölt tagok csökkentett csoportját a deklarálás típusa szerint csoportosítja a rendszer. Az egyes csoportokon belül:
  • A jelölt függvény tagjait a túlterhelés-felbontási prioritásalapján sorrendbe állítják. Ha a tag felüldefiniált, akkor a overload_resolution_priority az adott tag legkevésbé származtatott deklarációjából ered.
  • A deklarálási típuscsoportban található legmagasabbnál alacsonyabb overload_resolution_priority rendelkező tagok törlődnek.
• A csökkentett csoportok ezután újrakombinálásra kerülnek az alkalmazható jelölt függvénytagok végső halmazába.
• Ezután a megfelelő jelölt függvénytagok közül a legjobb tag található. Ha a készlet csak egy függvénytagot tartalmaz, akkor ez a függvénytag a legjobb függvénytag. Ellenkező esetben a legjobb függvénytag az az egyetlen függvénytag, amely jobb, mint az összes többi függvénytag az adott argumentumlista tekintetében, feltéve, hogy minden függvénytagot a §12.6.4.3szabályai szerint összehasonlítanak az összes többi függvénytaggal. Ha nincs pontosan egy olyan függvénytag, amely jobb, mint az összes többi függvénytag, akkor a függvénytagok meghívása nem egyértelmű, és kötési idejű hiba történik.

Például ez a funkció azt eredményezné, hogy a következő kódrészlet "Span"-t kinyomtassa, a "Tömb" helyett.

using System.Runtime.CompilerServices;

var d = new C1();
int[] arr = [1, 2, 3];
d.M(arr); // Prints "Span"

class C1
{
    [OverloadResolutionPriority(1)]
    public void M(ReadOnlySpan<int> s) => Console.WriteLine("Span");
    // Default overload resolution priority
    public void M(int[] a) => Console.WriteLine("Array");
}

Ennek a változásnak az a hatása, hogy a legtöbb származtatott típusok metszéséhez hasonlóan a túlterhelés-feloldási prioritáshoz hozzáadunk egy végleges metszést. Mivel ez a metszés a túlterhelés feloldási folyamatának végén történik, ez azt jelenti, hogy egy alaptípus nem teheti tagjait magasabb prioritásúvá, mint bármely származtatott típus. Ez szándékos, és megakadályozza, hogy fegyverkezési verseny történjen, ahol egy alaptípus megpróbálhat mindig jobb lenni, mint egy származtatott típus. Például:

using System.Runtime.CompilerServices;

var d = new Derived();
d.M([1, 2, 3]); // Prints "Derived", because members from Base are not considered due to finding an applicable member in Derived

class Base
{
    [OverloadResolutionPriority(1)]
    public void M(ReadOnlySpan<int> s) => Console.WriteLine("Base");
}

class Derived : Base
{
    public void M(int[] a) => Console.WriteLine("Derived");
}

A negatív számok használhatók, és egy adott túlterhelést az összes többi alapértelmezett túlterhelésnél rosszabbként jelölhetnek meg.

Egy tag overload_resolution_priority az adott tag legkevésbé származtatott deklarációjából ered. overload_resolution_priority nem öröklődik, és nem következtetik rá olyan illesztőtag által, amelyet egy típustag implementálhat, és ha egy tag Mx, implementál egy illesztőtagot Mi, a rendszer nem ad ki figyelmeztetést, ha Mx és Mi eltérő overload_resolution_priorities.

Megjegyzés: A szabály célja a params módosító viselkedésének replikálása.

System.Runtime.CompilerServices.OverloadResolutionPriorityAttribute

A BCL-hez a következő attribútumot vezetjük be:

namespace System.Runtime.CompilerServices;

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Constructor | AttributeTargets.Property, AllowMultiple = false, Inherited = false)]
public sealed class OverloadResolutionPriorityAttribute(int priority) : Attribute
{
    public int Priority => priority;
}

A C#-ban minden metódus alapértelmezett overload_resolution_priority értéke 0, kivéve, ha rendelkeznek a OverloadResolutionPriorityAttributeattribútummal. Ha ezzel az attribútummal vannak ellátva, akkor a overload_resolution_priority az attribútum első argumentumához megadott egész számérték.

Hiba OverloadResolutionPriorityAttribute-t alkalmazni a következő helyeken:

• Nem indexelő tulajdonságok
• Tulajdonság-, indexelő- vagy eseménykiegészítők
• Konverziós operátorok
• Lambdák
• Helyi függvények
• Befejezők
• Statikus konstruktorok

Az ezeken a helyeken a metaadatokban észlelt attribútumokat a C# figyelmen kívül hagyja.

Hiba a OverloadResolutionPriorityAttribute olyan helyre alkalmazni, ahol figyelmen kívül hagynák, például egy alapmetódus felülbírálásakor, mivel a prioritás egy tag legkevésbé származtatott deklarációjából kerül kiolvasásra.

Megjegyzés: Ez szándékosan eltér a params módosító viselkedésétől, ami lehetővé teszi az újradepecifikálást vagy a hozzáadást, ha figyelmen kívül hagyják.

Tagok hívhatósága

A OverloadResolutionPriorityAttribute egyik fontos kifogása, hogy bizonyos tagok hatékonyan lehívhatatlanok lehetnek a forrásból. Például:

using System.Runtime.CompilerServices;

int i = 1;
var c = new C3();
c.M1(i); // Will call C3.M1(long), even though there's an identity conversion for M1(int)
c.M2(i); // Will call C3.M2(int, string), even though C3.M1(int) has less default parameters

class C3
{
    public void M1(int i) {}
    [OverloadResolutionPriority(1)]
    public void M1(long l) {}

    [Conditional("DEBUG")]
    public void M2(int i) {}
    [OverloadResolutionPriority(1), Conditional("DEBUG")]
    public void M2(int i, [CallerArgumentExpression(nameof(i))] string s = "") {}

    public void M3(string s) {}
    [OverloadResolutionPriority(1)]
    public void M3(object o) {}
}

Ezekben a példákban az alapértelmezett prioritási túlterhelések gyakorlatilag csökevényesekké válnak, és csak néhány lépésben hívhatók meg, amelyek némi extra erőfeszítést igényelnek.

• A metódus átalakítása delegálttá, majd ennek használata.
  • Bizonyos referenciatípus-varianciaforgatókönyvek, például a M3(object), amely prioritást élvez a M3(string)-el szemben, esetén ez a stratégia sikertelen lesz.
  • A feltételes metódusok, például a M2, szintén nem hívhatók meg ezzel a stratégiával, mivel a feltételes metódusok nem konvertálhatók meghatalmazottakká.
• A UnsafeAccessor futtatókörnyezet funkciójával hívja meg a megfelelő szignatúrával.
• A reflexió manuális használata a metódusra mutató hivatkozás lekéréséhez, majd meghívásához.
• A nem újrafordított kód továbbra is régi metódusokat fog meghívni.
• A kézzel írt IL megadhatja, hogy mit választ.

Kérdések megnyitása

Bővítménymetódus csoportosítása (válasz)

A kiterjesztési metódusokat jelenleg csak a saját típusukon belül rendezik prioritási szempontból szerint. Például:

new C2().M([1, 2, 3]); // Will print Ext2 ReadOnlySpan

static class Ext1
{
    [OverloadResolutionPriority(1)]
    public static void M(this C2 c, Span<int> s) => Console.WriteLine("Ext1 Span");
    [OverloadResolutionPriority(0)]
    public static void M(this C2 c, ReadOnlySpan<int> s) => Console.WriteLine("Ext1 ReadOnlySpan");
}

static class Ext2
{
    [OverloadResolutionPriority(0)]
    public static void M(this C2 c, ReadOnlySpan<int> s) => Console.WriteLine("Ext2 ReadOnlySpan");
}

class C2 {}

Amikor túlterhelés-feloldást végzünk bővítménytagok esetén, ne a deklarált típus alapján rendezzünk, hanem tekintsük egy hatókörben lévő összes bővítményt.

Válasz

Mindig csoportosítunk. A fenti példa kinyomtatja Ext2 ReadOnlySpan

Attribútumok öröklése felülírások esetén (megválaszolva)

Örökölni kell az attribútumot? Ha nem, mi a elsőbbséget élvező tag prioritása?
Ha az attribútum egy virtuális tagon van megadva, az attribútum megismétléséhez az adott tag felülbírálása szükséges?

Válasz

Az attribútum nem lesz öröklöttként megjelölve. Egy tag legkevésbé származtatott deklarációját fogjuk megvizsgálni a túlterhelés-feloldási prioritás meghatározásához.

Alkalmazáshiba vagy figyelmeztetés felülbíráláskor (válasz)

class Base
{
    [OverloadResolutionPriority(1)] public virtual void M() {}
}
class Derived
{
    [OverloadResolutionPriority(2)] public override void M() {} // Warn or error for the useless and ignored attribute?
}

Milyen intézkedéseket kell tennünk egy OverloadResolutionPriorityAttribute olyan környezetben való alkalmazásakor, ahol azt figyelmen kívül hagyják, például felülírás esetén:

1. Ne csináljon semmit, hagyja, hogy csendben figyelmen kívül hagyják.
2. Adjon meg egy figyelmeztetést, amely szerint az attribútum figyelmen kívül lesz hagyva.
3. Olyan hibát ad ki, amely miatt az attribútum nem engedélyezett.

A 3 a legvigyázatosabb megközelítés, ha úgy véljük, hogy a jövőben lehetőség nyílik arra, hogy egy felülbírálást engedélyezzünk ehhez az attribútumhoz.

Válasz

3-mal fogunk menni, és az alkalmazást blokkoljuk azokon a helyeken, ahol azt figyelmen kívül hagynák.

Implicit felület implementálása (megválaszolva)

Mi legyen az implicit felület implementációjának viselkedése? Szükség van-e OverloadResolutionPrioritymegadására? Mi legyen a fordító viselkedése, ha prioritás nélküli implicit implementációval találkozik? Ez szinte biztosan megtörténik, mivel egy felületi kódtár frissíthető, de implementáció nem. A params itt korábbi gyakorlatként szolgál, amely nem adja meg és nem viszi át az értéket:

using System;

var c = new C();
c.M(1, 2, 3); // error CS1501: No overload for method 'M' takes 3 arguments
((I)c).M(1, 2, 3);

interface I
{
    void M(params int[] ints);
}

class C : I
{
    public void M(int[] ints) { Console.WriteLine("params"); }
}

A lehetőségek a következők:

1. Kövesse params. OverloadResolutionPriorityAttribute nem lesz implicit módon átvitve, vagy meg kell adni.
2. Vigye át implicit módon az attribútumot.
3. Ne vigye át implicit módon az attribútumot, és követelje meg, hogy a hívás helyszínén adja meg.
   1. Ez egy további kérdést is felvet: milyen legyen a viselkedés, amikor a fordító lefordított hivatkozásokkal találkozik ebben a forgatókönyvben?

Válasz

1-zel megyünk.

További alkalmazáshibák (Megválaszolva)

Van még néhány hely, mint például a és a, amelyeket meg kell erősíteni. Ezek közé tartoznak a következők:

• Konverziós operátorok – A specifikáció soha nem mondja, hogy a konverziós operátorok túlterhelés-feloldáson mennek keresztül, így az implementáció blokkolja az alkalmazásokat ezeken a tagokon. Ezt meg kell erősíteni?
• Lambdas - Hasonlóképpen, a lambdákra soha nem vonatkozik a túlterhelés feloldása, így a megvalósítás blokkolja őket. Ezt meg kell erősíteni?
• Destruktorok – ismét, jelenleg letiltva.
• Statikus konstruktorok – ismét, jelenleg letiltva.
• Helyi függvények – Ezek jelenleg nincsenek letiltva, mert túlterhelésfeloldáson esnek át, egyszerűen nem lehet túlterhelni őket. Ez hasonló ahhoz, ahogyan nem hibázunk, ha az attribútumot olyan típusú tagra alkalmazza a rendszer, amely nem túlterhelt. Meg kell erősíteni ezt a viselkedést?

Válasz

A fenti helyek mindegyike le van tiltva.

Langversion Viselkedés (Megválaszolva)

A megvalósítás jelenleg csak a OverloadResolutionPriorityAttribute alkalmazásakor okoz langversion-hibákat, nem, ha az ténylegesen hatással van bármire. Ez a döntés azért született, mert vannak olyan API-k, amelyeket a BCL hozzáad (most és idővel is), amelyek elkezdik használni ezt az attribútumot; ha a felhasználó manuálisan állítja vissza a nyelvi verziót a C# 12-es vagy korábbi verziójára, akkor láthatják ezeket a tagokat, és a langversion viselkedésétől függően a következők lehetnek:

• Ha figyelmen kívül hagyjuk az attribútumot a C# <13-ban, kétértelmű hibába ütközik, mert az API valójában nem egyértelmű az attribútum nélkül, vagy;
• Ha hiba történik, amikor az attribútum hatással van az eredményre, olyan hibába ütközik, amely szerint az API nem érhető el. Ez különösen rossz lesz, mert a Debug.Assert(bool) prioritása csökken a .NET 9-ben.
• Ha csendesen módosítjuk a felbontást, a különböző fordítóverziók eltérő viselkedést tapasztalhatnak, ha az egyik megérti az attribútumot, a másik pedig nem.

Az utolsó viselkedést azért választották ki, mert ez a legáttekintőbb kompatibilitást eredményezi, de a változó eredmény néhány felhasználó számára meglepő lehet. Megerősítsük ezt, vagy válasszunk a többi lehetőség közül?

Válasz

Az 1. lehetőséggel megyünk, és csendben figyelmen kívül hagyjuk az attribútumot az előző nyelvi verziókban.

Alternatívák

Egy korábbi javaslat egy BinaryCompatOnlyAttribute megközelítést próbált meghatározni, amely nagyon agresszív volt a dolgok láthatóságból történő eltávolításában. Ez azonban sok olyan nehéz megvalósítási problémával rendelkezik, amelyek vagy azt jelentik, hogy a javaslat túl erős ahhoz, hogy hasznos legyen (például megakadályozza a régi API-k tesztelését), vagy olyan gyenge, hogy kihagyott néhány eredeti célt (például olyan API-t, amely egyébként nem egyértelműnek tekinthető egy új API-nak). Ezt a verziót az alábbiakban replikáljuk.

BinaryCompatOnlyAttribute javaslat (elavult)

BinaryCompatOnlyAttribute

Részletes kialakítás

System.BinaryCompatOnlyAttribute

Bevezetünk egy új fenntartott attribútumot:

namespace System;

// Excludes Assembly, GenericParameter, Module, Parameter, ReturnValue
[AttributeUsage(AttributeTargets.Class
                | AttributeTargets.Constructor
                | AttributeTargets.Delegate
                | AttributeTargets.Enum
                | AttributeTargets.Event
                | AttributeTargets.Field
                | AttributeTargets.Interface
                | AttributeTargets.Method
                | AttributeTargets.Property
                | AttributeTargets.Struct,
                AllowMultiple = false,
                Inherited = false)]
public class BinaryCompatOnlyAttribute : Attribute {}

Egy típustagra alkalmazva az adott tagot a fordító minden helyen elérhetetlennek tekinti, ami azt jelenti, hogy nem járul hozzá a tagok kereséséhez, a túlterhelés feloldásához vagy más hasonló folyamathoz.

Akadálymentességi tartományok

Frissítjük §7.5.3 Akadálymentességi tartományokat, ahogy az alábbi:

A tag hozzáférési tartománya a programszöveg (esetleg különálló) szakaszaiból áll, amelyekben a taghoz való hozzáférés engedélyezett. A tagok akadálymentességi tartományának meghatározásához a rendszer azt mondja, hogy egy tag legfelső szintű, ha nem egy típuson belül deklarálva van, és a tag beágyazott, ha más típuson belül deklarálják. Ezenkívül a program programszövege a program összes fordítási egységében található összes szövegként van definiálva, a típus programszövege pedig az adott típusú type_declaration-type_declarationösszes szövegként van definiálva (beleértve a típusba beágyazott típusokat is).

Az előre definiált típusú (például object, intvagy double) akadálymentességi tartomány korlátlan.

A program T deklarált legfelső szintű kötetlen típusú (P) akadálymentességi tartománya a következőképpen van definiálva:

• Ha TBinaryCompatOnlyAttributevan megjelölve, a T akadálymentességi tartománya teljesen elérhetetlen a P programszövegéhez és az Phivatkozó programokhoz.
• Ha a T deklarált hozzáférhetősége nyilvános, a T hozzáférhetőségi tartománya a P programszövege, valamint bármely P-ra hivatkozó program.
• Ha a T deklarált hozzáférhetősége belső, akkor a T hozzáférhetőségi tartománya a Pprogramszövegére vonatkozik.

Megjegyzés: Ezekből a definíciókból következik, hogy a legfelső szintű kötetlen típus akadálymentességi tartománya mindig legalább annak a programnak a programszövege, amelyben a típus deklarálva van. végjegyzet

A létrehozott T<A₁, ..., Aₑ> akadálymentességi tartománya a kötetlen általános típusú T akadálymentességi tartományának és a A₁, ..., Aₑtípusargumentumok akadálymentességi tartományának metszete.

A beágyazott tag akadálymentességi tartománya M egy program TP típusában deklarálva a következőképpen van definiálva (figyelemmel arra, hogy maga a M valószínűleg típus lehet):

• Ha MBinaryCompatOnlyAttributevan megjelölve, a M akadálymentességi tartománya teljesen elérhetetlen a P programszövegéhez és az Phivatkozó programokhoz.
• Ha a M deklarált hozzáférhetősége public, akkor a M hozzáférhetőségi tartománya a Thozzáférhetőségi tartománya.
• Ha a M deklarált akadálymentessége protected internal, akkor a D legyen a P programszövegének és a T-ből származó bármely típusú programszövegnek az egyesítése, amelyet Pkívül deklaráltak. A M akadálymentességi tartománya a T akadálymentességi tartománya és Dközötti metszet.
• Ha a M deklarált akadálymentessége private protected, D legyen a P programszövegének, valamint a T programszövegének és a Tszármazó bármilyen típusnak a metszete. A M akadálymentességi tartománya a T akadálymentességi tartománya és Dközötti metszet.
• Ha a M deklarált akadálymentessége protected, akkor D legyen a Tprogramszövegének és bármelyik Ttípusból származtatott programszöveg egyesítője. A M akadálymentességi tartománya a T akadálymentességi tartománya és Dközötti metszet.
• Ha a M deklarált akadálymentessége internal, akkor a M akadálymentességi tartománya a T akadálymentességi tartományának és a Pprogramszövegének metszete.
• Ha a M deklarált hozzáférhetősége private, a M hozzáférhetőségi tartománya a Tprogramkód.

Ezeknek a kiegészítéseknek a célja, hogy a BinaryCompatOnlyAttribute megjelölt tagok teljesen elérhetetlenek legyenek bármely helyre, ne vegyenek részt a tagok keresésében, és ne befolyásolhassák a program többi részét. Következésképpen ez azt jelenti, hogy nem implementálhatják az interfésztagokat, nem hívhatják egymást, és a virtuális metódusokat nem lehet felülbírálni, elrejteni, vagy az interfésztagokat implementálni. Azt, hogy ez túl szigorú-e, az alábbiakban számos nyitott kérdés tárgya.

Megoldatlan kérdések

Virtuális módszerek és felülírás

Mi a teendő, ha egy virtuális metódus BinaryCompatOnlyvan megjelölve? Előfordulhat, hogy egy származtatott osztály metódus felülbírálásai nem is szerepelnek az aktuális szerelvényben, és lehet, hogy a programozó olyan metódus új verzióját szeretné bevezetni, amely például csak a visszatérési típusában különbözik, ami a C# esetében általában nem teszi lehetővé a metódus túlterhelést. Mi történik a korábbi metódus felülírásával újrafordítás esetén? Felülbírálhatják a BinaryCompatOnly tagot, ha BinaryCompatOnly-ként is meg vannak jelölve?

Használat ugyanabban a DLL-ben

Ez a javaslat azt állítja, hogy BinaryCompatOnly tagok sehol nem láthatók, még a jelenleg összeállított közgyűlésen sem. Ez túl szigorú, vagy a BinaryCompatAttribute tagoknak esetleg egymáshoz kell láncolódniuk?

Interfésztagok implicit implementálása

Képesnek kell-e lennie BinaryCompatOnly tagoknak a felülettagok implementálására? Vagy meg kell akadályozni őket ebben. Ehhez az lenne szükséges, hogy amikor egy felhasználó egy implicit interfész implementációt szeretne átalakítani BinaryCompatOnly-ra, akkor ezen felül explicit interfész implementációt is kell biztosítania. Valószínűleg klónoznia kellene a BinaryCompatOnly tag törzsét, mivel az explicit interfész implementáció már nem látná az eredeti tagot.

A BinaryCompatOnly megjelölt felülettagok implementálása

Mi a teendő, ha egy felülettag BinaryCompatOnlyvan megjelölve? A típusnak továbbra is rendelkeznie kell egy implementációval az adott tag számára; lehet, hogy egyszerűen ki kell mondanunk, hogy a felület tagjai nem jelölhetők meg BinaryCompatOnly.