¿Por qué no es posible sobrecargar el operador de asignación compuesta en C #?

El título es engañoso, así que lea la pregunta completa :-) .

Por "operador de asignación compuesto" tengo en mente una construcción como esta op=, por ejemplo +=. El operador de asignación puro ( =) no pertenece a mi pregunta.

Por "por qué" no me refiero a una opinión, sino a un recurso (libro, artículo, etc.) cuando algunos de los diseñadores, o sus compañeros de trabajo, etc. expresan su razonamiento (es decir, la fuente de la elección del diseño).

Estoy desconcertado por la asimetría que se encuentra en C ++ y C # ( sí, sé que C # no es C ++ 2.0 ): en C ++ sobrecargaría el operador +=y luego escribiría casi automáticamente el +operador apropiado basándose en el operador previamente definido. En C # es al revés: se sobrecarga +y +=se sintetiza para usted.

Si no me equivoco, el enfoque posterior mata la posibilidad de optimización en caso de que sea real +=, porque se debe crear un nuevo objeto. Por lo tanto, tiene que haber una gran ventaja de este enfoque, pero MSDN es demasiado tímido para contarlo.

Y me pregunto cuál es esa ventaja, por lo que si vio una explicación en un libro de C #, un video de charla técnica, una entrada de blog, le agradeceré la referencia.

Lo más parecido que encontré es un comentario en el blog de Eric Lippert ¿Por qué los operadores sobrecargados siempre están estáticos en C #? por Tom Brown. Si la sobrecarga estática se decidió primero, simplemente dicta qué operadores se pueden sobrecargar para las estructuras. Esto dicta aún más qué se puede sobrecargar para las clases.

c# language-design operators

— Greenoldman
fuente

¿Tiene un enlace para el nuevo estilo C ++? Ingenuamente, la sobrecarga +=primero parece absurda; ¿Por qué sobrecargaría una operación combinada en lugar de las partes de ella?

— Telastyn

Creo que el término para estos es "operadores de asignación compuesta".

— Ixrec

@greenoldman Telastyn probablemente estaba dando a entender que implementar + = en términos de + parece más natural que al revés, ya que semánticamente + = es una composición de + y =. Que yo sepa , tener + call + = es en gran medida un truco de optimización.

— Ixrec

@Ixrec: a veces, a + = b tiene sentido, mientras que a = a + b no: tenga en cuenta que la identidad puede ser importante, una A no puede duplicarse, lo que sea. A veces, a = a + b tiene sentido, mientras que a + = b no: considere cadenas inmutables. Entonces, uno realmente necesita la capacidad de decidir cuál sobrecargar por separado. Por supuesto, es una buena idea generar automáticamente el que falta, si existen todos los bloques de construcción necesarios y no se deshabilita explícitamente. No es que C # permita ese cajero automático, afaik.

— Deduplicador

@greenoldman: entiendo esa motivación, pero personalmente, encontraría que *=mutar un tipo de referencia es semánticamente incorrecto.

— Telastyn

No puedo encontrar la referencia para esto, pero entendí que el equipo de C # quería proporcionar un subconjunto sensato de sobrecarga del operador. En ese momento, la sobrecarga del operador tuvo una mala reputación. La gente afirmó que ofuscaba el código y que solo podía usarse para el mal. Cuando C # se diseñó, Java nos había demostrado que ninguna sobrecarga de operadores era un poco molesta.

Entonces, C # quería equilibrar la sobrecarga del operador para que fuera más difícil hacer el mal, pero también se podían hacer cosas buenas. Cambiar la semántica de la asignación fue una de esas cosas que siempre se consideró malvada. Al permitir que +=sus parientes se sobrecarguen, permitiría ese tipo de cosas. Por ejemplo, si +=muta la referencia en lugar de hacer una nueva, no seguiría la semántica esperada, lo que provocaría errores.

— Telastyn
fuente

Gracias, si no le importa, mantendré esta pregunta abierta un poco más, y si nadie lo supera con el razonamiento del diseño real, lo cerraré aceptando el suyo. Una vez mas, Gracias.

— greenoldman

@greenoldman, como deberías. También espero que alguien venga con una respuesta con referencias más concretas.

— Telastyn

Entonces, ¿este es un lugar donde la imposibilidad de hablar sobre el puntero y el pointee cómodamente y sin ambigüedades levanta su cabeza? Maldita vergüenza.

— Deduplicador

"La gente afirmó que ocultaba el código". Sin embargo, sigue siendo cierto, ¿has visto algunas de las bibliotecas F #? Ruido del operador. Ej. Quanttec.com/fparsec

— Den