Pourquoi il n'est pas possible de surcharger l'opérateur d'affectation composé en C #?

Le titre est trompeur, alors lisez toute la question :-) .

Par «opérateur d'affectation composé», j'ai en tête une construction comme celle-ci op=, par exemple +=. L'opérateur d'affectation pure ( =) ne fait pas partie de ma question.

Par «pourquoi», je ne veux pas dire une opinion, mais une ressource (livre, article, etc.) lorsque certains des designers, ou leurs collègues, etc. expriment leur raisonnement (c'est-à-dire la source du choix de conception).

Je suis intrigué par l'asymétrie trouvée en C ++ et C # ( oui, je sais que C # n'est pas C ++ 2.0 ) - en C ++, vous surchargeriez l'opérateur +=, puis écririez presque automatiquement l' +opérateur approprié en vous appuyant sur l'opérateur précédemment défini. En C #, c'est l'inverse - vous surchargez +et +=est synthétisé pour vous.

Si je ne me trompe pas, l'approche ultérieure tue une chance d'optimisation en cas de réel +=, car un nouvel objet doit être créé. Il doit donc y avoir un gros avantage d'une telle approche, mais MSDN est trop timide pour en parler.

Et je me demande quel est cet avantage - donc si vous avez repéré une explication dans un livre en C #, une vidéo tech-talk, une entrée de blog, je serai reconnaissant pour la référence.

La chose la plus proche que j'ai trouvée est un commentaire sur le blog d'Eric Lippert Pourquoi les opérateurs surchargés sont-ils toujours statiques en C #? par Tom Brown. Si la surcharge statique a été décidée en premier, elle dicte simplement quels opérateurs peuvent être surchargés pour les structures. Cela dicte davantage ce qui peut être surchargé pour les classes.

c# language-design operators

— greenoldman
source

Avez-vous un lien pour le nouveau style C ++? Naïvement, la surcharge +=semble d'abord absurde; pourquoi voudriez-vous surcharger une opération combinée plutôt que ses parties?

— Telastyn

Je crois que le terme pour ceux-ci est "opérateurs d'affectation composés".

— Ixrec

@greenoldman Telastyn impliquait probablement que la mise en œuvre de + = en termes de + semble plus naturelle que l'inverse, car sémantiquement + = est une composition de + et =. À ma connaissance , avoir + call + = est en grande partie une astuce d'optimisation.

— Ixrec

@Ixrec: Parfois, a + = b est logique, tandis que a = a + b ne l'est pas: considérez que l'identité peut être importante, un A ne peut pas être dupliqué, peu importe. Parfois, a = a + b est logique, tandis que a + = b ne l'est pas: considérez les chaînes immuables. Donc, on a réellement besoin de pouvoir décider lequel surcharger séparément. Bien sûr, la génération automatique de celui qui manque, si tous les blocs de construction nécessaires existent et qu'il n'est pas explicitement désactivé, est une bonne idée. Non pas que C # permette cette atmosphère, afaik.

— Déduplicateur

@greenoldman - Je comprends cette motivation, mais personnellement, je trouverais que la *=mutation d'un type de référence est sémantiquement incorrecte.

— Telastyn

Je ne trouve pas la référence pour cela, mais je croyais que l'équipe C # voulait fournir un sous-ensemble sain de surcharge d'opérateur. À l'époque, la surcharge de l'opérateur avait un mauvais coup dur. Les gens ont affirmé qu'il masquait le code et ne pouvait être utilisé que pour le mal. Au moment de la conception de C #, Java nous avait montré qu'aucune surcharge d'opérateur n'était un peu ennuyeuse.

C # voulait donc équilibrer la surcharge des opérateurs afin qu'il soit plus difficile de faire le mal, mais vous pouviez aussi faire de belles choses. Changer la sémantique de l'affectation était l'une de ces choses qui étaient toujours considérées comme mauvaises. En permettant à +=ses proches d'être surchargés, cela permettrait ce genre de chose. Par exemple, si +=la référence était modifiée plutôt que d'en créer une nouvelle, elle ne suivrait pas la sémantique attendue, ce qui entraînerait des bogues.

— Telastyn
source

Merci, si cela ne vous dérange pas, je garderai cette question ouverte un peu plus longtemps, et si personne ne vous bat avec le raisonnement de la conception réelle, je terminerai en acceptant la vôtre. Encore une fois merci.

— greenoldman

@greenoldman - vous aussi. J'espère aussi que quelqu'un viendra avec une réponse avec des références plus concrètes.

— Telastyn

Donc, c'est un endroit où l'impossibilité de parler à la fois du pointeur et de la pointe pointe confortablement et sans ambiguïté sa tête? Quelle honte.

— Déduplicateur

"Les gens ont affirmé qu'il masquait le code" - c'est toujours vrai cependant, avez-vous vu certaines des bibliothèques F #? Bruit de l'opérateur. Par exemple quanttec.com/fparsec

— Den