Proposition officielle d'unions de types par l'�quipe de conception du langage C#

Pour tenter de fournir des solutions � tous les cas d'utilisation en d�clarant quatre cat�gories

Proposition officielle d'unions de types par l'�quipe de conception du langage C#, pour tenter de fournir des solutions � tous les cas d'utilisation en d�clarant quatre cat�gories.

L'�quipe de conception du langage C# propose les unions de types (aussi appel�es unions discrimin�es) en C#. La proposition officielle tente d'apporter des solutions � tous les cas d'utilisation en les classant en quatre cat�gories. En effet, il peut �tre impossible de satisfaire certains cas d'utilisation sans en compromettre d'autres, et s'il y a plusieurs types, il vaut mieux s'efforcer de faire en sorte qu'ils aient l'air de fonctionner de la m�me mani�re autant que possible.

Lorsque vous d�veloppez un logiciel, vous pouvez rencontrer des situations o� les valeurs que vous souhaitez stocker dans une variable ne sont pas toujours du m�me type � chaque fois. Bien que vous ne soyez g�n�ralement pas pr�occup� par le fait de stocker des cha�nes de caract�res et des nombres au m�me endroit, vous pouvez avoir besoin de stocker l'un des quelques types apparent�s en fonction de ce que les donn�es sont cens�es repr�senter � ce moment-l�.

Par exemple, votre application peut avoir une d�finition de client et une d�finition de fournisseur qui ne partagent que certaines des m�mes propri�t�s et vous pouvez avoir besoin d'effectuer une op�ration similaire sur les deux d'une mani�re qui d�pend des diff�rences.

Typiquement, c'est l� que vous pouvez choisir de distribuer ces impl�mentations sp�cialis�es dans les types eux-m�mes et de les exposer par le biais de m�thodes abstraites communes ou d'interfaces. Toutefois, il ne s'agit l� que d'une bonne pratique lorsque ces types existent principalement pour l'objectif de l'op�ration ou qu'il est logique que l'op�ration apparaisse comme une partie intrins�que du type. Si les types ont un objectif plus large, il n'est pas souhaitable de les polluer avec des m�thodes de ce type.

L'autre solution consiste � faire en sorte que la m�me logique g�re les deux types, et si vous faites cela, vous devrez � un moment donn� d�clarer un param�tre ou une variable qui peut contenir l'un ou l'autre.

Vous pourriez penser que vous pouvez encore r�soudre ce probl�me par l'h�ritage, en d�finissant � la fois Customer et le Supplier comme des classes dans une hi�rarchie avec un type de base commun comme Contact. Cependant, si vous n'�tes pas en mesure de d�finir une telle relation, soit parce que vous ne poss�dez pas la d�finition de ces types, soit parce que vous avez trop de situations similaires et que vous ne pouvez en r�soudre qu'une seule par l'h�ritage, soit parce que vous choisissez de ne pas int�grer les exigences de l'op�ration sp�cifique dans la d�finition des donn�es, le seul choix possible est de d�clarer la variable en tant qu'objet et de la laisser �tre n'importe quoi.

Bien que cette solution puisse fonctionner, elle ne vous permet pas de contr�ler votre code par le biais de la documentation et des commentaires. Si vous �tes courageux, vous pouvez concevoir des hi�rarchies de cas sp�ciaux de types enveloppants � placer autour de vos valeurs, ou des types agr�g�s personnalis�s qui agissent comme des gardiens autour de tous les types de valeurs que vous voulez �ventuellement stocker dans la variable, ce qui prend du temps et est lourd, surtout si vous avez beaucoup de situations similaires mais qu'elles impliquent toutes des ensembles de types diff�rents.

Il serait pr�f�rable que C# vous permette de d�clarer un type qui vous autorise � stocker un type parmi un nombre limit� d'autres types au m�me endroit, et qu'il fasse tout le travail de protection des variables pour vous. De nombreux autres langages font d�j� cela. Ils appellent g�n�ralement ces types sp�ciaux des unions discrimin�es, des unions �tiquet�es, des types de somme ou des unions de types. Tous r�solvent le probl�me de permettre � une seule variable de contenir des valeurs d'une ou plusieurs formes limit�es. Il est temps que C# dispose d'une fonctionnalit� qui le permette �galement.


Solutions : les unions de types pour C#

Vous pourriez imaginer que l'impl�mentation la plus appropri�e pour les types d'union en C# est une hi�rarchie de classes avec une base abstraite repr�sentant l'union elle-m�me et tous les cas sp�cifiques de l'union en tant que classe d�riv�e, parce que cela correspond vraiment bien aux concepts d�j� pr�sents dans le langage. Cela fonctionne g�n�ralement bien lorsque vous avez un cas d'utilisation sp�cifique � l'esprit et que vous concevez un ensemble sp�cifique de classes pour r�soudre ce probl�me sp�cifique. Cependant, l'impl�mentation des unions sous forme de hi�rarchies de classes pr�sente certains inconv�nients.

• L'un d'eux est l'impossibilit� de contraindre la hi�rarchie, car les langages orient�s objet sont g�n�ralement ouverts � l'h�ritage.
  
  Je sais qu'il n'y a que trois sous-types possibles, mais pourquoi le compilateur me demande-t-il d'avoir une valeur par d�faut dans mon expression switch ?
• Un autre probl�me est l'incapacit� de repr�senter des unions de types non apparent�s qui existent en dehors d'une hi�rarchie unique ou m�me de restreindre les valeurs � un sous-ensemble de types � l'int�rieur de la m�me hi�rarchie.
  
  Je souhaite que ce param�tre soit limit� aux chats et aux chiens, et non � tous les animaux.
• En raison de l'impl�mentation de la hi�rarchie des classes, la seule fa�on d'inclure une valeur d'un type qui existe d�j� est d'utiliser une classe qui fait partie de la hi�rarchie d'union pour envelopper la valeur.
  
  Je dois soit saisir ces champs en tant qu'objet et faire confiance � moi-m�me et � mon �quipe pour toujours faire ce qu'il faut, soit envelopper mes valeurs dans de nouvelles instances de classe chaque fois que je veux les stocker dans la variable.
• Enfin, les classes en C# n�cessitent une allocation pour �tre repr�sent�es et ne peuvent pas contenir de valeurs telles que les types ref, qui peuvent �tre n�cessaires pour des sc�narios sp�cifiques.
  
  J'aimerais pouvoir utiliser les unions dans mon pipeline graphique, mais elles provoquent trop de gen 0.

Pour ces raisons, il peut �tre n�cessaire d'avoir plus d'un type d'union, car il peut �tre impossible de satisfaire certains cas d'utilisation sans en compromettre d'autres, et s'il y a plusieurs types, il vaut mieux s'efforcer de faire en sorte qu'ils aient l'air de fonctionner de la m�me mani�re autant que possible.


La proposition officielle tente d'apporter des solutions � tous les cas d'utilisation en les classant en quatre cat�gories :

Standard : Cas d'utilisation o� l'union et ses membres peuvent �tre d�finis ensemble, parce qu'ils ont une raison pr�dominante d'appartenir ensemble et que vous avez l'intention d'utiliser les membres comme des classes � part enti�re. L'allocation n'est pas un probl�me car vous auriez allou� les classes de toute fa�on.

Sp�cialis� : Cas d'utilisation qui doivent �viter les allocations ou qui n�cessitent l'utilisation de types sp�ciaux et qui sont pr�ts � accepter certaines limitations pour y parvenir.

Ad Hoc : Cas d'utilisation n�cessitant la formation d'unions � partir de types existants, �ventuellement non apparent�s, et o� des unions d�clar�es de mani�re similaire avec les m�mes types de membres sont interchangeables les unes avec les autres.

Personnalis� : Cas d'utilisation qui ne correspondent pas aux autres cat�gories.

Pour voir en d�tails la proposition et des exemples, vous pouvez explorer la documentation compl�te.

Source : "Type Unions for C#"

Et vous ?

Avez-vous d�j� utilis� les unions de types dans d'autres langages, et si oui qu'en pensez-vous ?
Pensez-vous que cette proposition est cr�dible ou pertinente ?

Voir aussi :

C# 13 : D�couvrez les derni�res fonctionnalit�s en avant-premi�re, dont l'am�lioration de la collection params et la r�solution des surcharges, ainsi que l'ajout des propri�t�s partielles

Annonces et mises � jour de .NET � la Microsoft Build 2024 : int�gration profonde de l'IA, simplification du d�veloppement-natif avec .Net Aspire, ainsi que des am�liorations des fonctionnalit�s C# pour C# 13