Pihentető műszakkezelői követelmények

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/4666

Összefoglalás

A műszakműveleti követelmények enyhülnek, így a jobb oldali operandus már nem korlátozódik csak int.

Motiváció

Ha nem inttípusokkal dolgozik, nem ritka, hogy egy másik számítás eredménye alapján módosít, például a leading zero countalapján történő módosítással. A leading zero count természetes típusa megegyezik a bemeneti típussal (TSelf), ezért sok esetben az eredményt int-re kell átalakítania, még akkor is, ha az eredmény már a tartományon belül van.

A könyvtárak által elérhetővé tenni tervezett általános matematikai interfészek kontextusában ez potenciálisan problémás lehet, mivel a típus nem jól ismert, ezért előfordulhat, hogy a int konvertálása nem lehetséges, vagy nem is jól definiált.

Részletes kialakítás

Shift operátorok

§12.11 szövegét a következőképpen kell átírni:

- When declaring an overloaded shift operator, the type of the first operand must always be the class or struct containing the operator declaration,
and the type of the second operand must always be int.
+ When declaring an overloaded shift operator, the type of the first operand must always be the class or struct containing the operator declaration.

Vagyis megmarad az a korlátozás, hogy az első operandus az operátor-deklarációt tartalmazó osztály vagy szerkezet legyen. Már nincs érvényben a korlátozás, miszerint a második operandusnak int-nak kell lennie.

Bináris operátorok

A 14.10.3 § újrafogalmazandó a következőképpen:.

-*  A binary `<<` or `>>` operator must take two parameters, the first of which must have type `T` or `T?` and the second of which must have type `int` or `int?`, and can return any type.
+*  A binary `<<` or `>>` operator must take two parameters, the first of which must have type `T` or `T?`, and can return any type.

Vagyis az első paraméter T vagy T? korlátozása megmarad. Bár a második operandusra vonatkozó int vagy int? korlátozás el lett távolítva.

Bináris operátor túlterhelésének feloldása

A §11.4.5 első felsorolásjelét a következőképpen kell újrafogalmazni:

• A X és a Y által a operator op(x,y) művelethez megadott, felhasználó által megadott jelölt operátorok készlete lesz meghatározva. A halmaz a X és által biztosított jelölt operátorok egyesítéséből áll , kivéve, ha az operátor műszak-operátor, a Yáltal biztosított jelölt operátorokat , amelyek mindegyike a 11.4.6. § . Ha X és Y azonos típusúak, vagy ha a X és a Y egy közös alaptípusból származik, akkor a megosztott jelölt operátorok csak egyszer fordulnak elő az egyesített csoportban.

Vagyis a műszakos operátorok esetében a jelölt operátorok csak a Xtípus által megadott operátorok.

Hátránya

A felhasználók olyan operátorokat határozhatnak meg, amelyek nem követik az ajánlott irányelveket, például a cout << "string" C#-ban való implementálását.

Alternatívák

A kódtárak által közzétett általános matematikai felületek ehelyett explicit módon elnevezett metódusokat tehetnek közzé. Ez megnehezítheti a kód olvasását/karbantartását.

Az általános matematikai felületekhez szükség lehet az eltolás int és a konverzió végrehajtására. Ez az átalakítás költséges lehet, vagy a szóban forgó típustól függően nem lehetséges.

Megoldatlan kérdések

Van-e aggodalom a szándék megőrzésével kapcsolatban azzal, hogy a második operandus miért van korlátozva int-ra?

Tervezői értekezletek

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-02-09.md