Чому не можна перевантажувати оператор присвоєння складових на C #?

Назва вводить в оману, тому прочитайте все питання :-) .

op=Наприклад, "оператор присвоєння складових" я маю на увазі таку конструкцію, як ця +=. Чистий оператор призначення ( =) не належить до мого питання.

Під "чому" я маю на увазі не думку, а ресурс (книга, стаття тощо), коли хтось із дизайнерів або їх колег тощо висловлює свої міркування (тобто джерело вибору дизайну).

Мене спантеличує асиметрія, знайдена у C ++ та C # ( так, я знаю, що C # не є C ++ 2.0 ) - у C ++ ви перевантажуєте оператора, +=а потім майже автоматично записуєте відповідного +оператора, спираючись на раніше визначений оператор. У C # це навпаки - ти перевантажуєшся +і +=синтезується для тебе.

Якщо я не помиляюсь, більш пізній підхід вбиває шанс на оптимізацію у випадку фактичного +=, оскільки новий об’єкт повинен бути створений. Тож має бути якась велика перевага такого підходу, але MSDN занадто сором’язливо, щоб про це говорити.

І мені цікаво, у чому полягає ця перевага - тому, якщо ви помітили пояснення в якійсь книжці на C #, відео в технічному спілкуванні, записі в блозі, я буду вдячний за довідку.

Найближче, що я знайшов, - це коментар до блогу Еріка Ліпперта Чому перевантажені оператори завжди статичні в C #? Том Браун. Якщо статичне перевантаження було вирішено спочатку, воно просто диктує, які оператори можуть бути перевантажені для структур. Це далі диктує, що можна перевантажувати для занять.

c# language-design operators

— greenoldman
джерело

Чи є у вас посилання на новий стиль C ++? Наївно, перевантаження +=передусім здається абсурдним; чому б ви перевантажували комбіновану операцію, а не її частини?

— Теластин

Я вважаю, що термін для них - "оператори складного призначення".

— Іксрек

@greenoldman Теластин, ймовірно, мав на увазі, що реалізація + = з точки зору + здається більш природною, ніж навпаки, оскільки семантично + = є складом + і =. Наскільки мені відомо , наявність + call + = є значною мірою оптимізаційним трюком.

— Іксрек

@Ixrec: Іноді a = = має сенс, тоді як a = a + b не має: вважайте, що ідентичність може бути важливою, A не можна дублювати, як би там не було. Іноді a = a + b має сенс, тоді як a = = b не має: Розгляньте незмінні рядки. Отже, насправді потрібна можливість вирішити, яку перевантажувати окремо. Звичайно, автоматична генерація відсутнього, якщо всі необхідні складові блоки існують і явно не вимикається, є хорошою ідеєю. Не те, що C # дозволяє той атм, afaik.

— Дедуплікатор

@greenoldman - Я розумію, що мотивація, але особисто я вважаю, що *=мутація еталонного типу є семантично неправильною.

— Теластин

Я не можу знайти посилання на це, але я розумію, що команда C # хотіла забезпечити здоровий підмножина перевантаження оператора. У той час перевантаження оператора мало поганий реп. Люди стверджували, що це заплутано код, і його можна використовувати лише для зла. На той час, коли C # розроблявся, Java показала нам, що жодна перевантаження операторів не дратує.

Тож C # хотів врівноважити перевантаження оператора, щоб було складніше робити зло, але і ви могли зробити приємні речі. Зміна семантики призначення було однією з тих речей, які вважалися завжди злими. Дозволяючи +=перевантажувати і споріднювати його родичів, це дозволило б таке. Наприклад, якщо +=мутувати посилання, а не робити нове, воно не слідкуватиме очікуваній семантиці, що призводить до помилок.

— Теластин
джерело

Дякую, якщо ви не заперечуєте, я триматиму це питання відкритим трохи довше, і якщо ніхто не поб'є вас обґрунтуванням фактичного дизайну, я закрию його прийняттям вашого. Ще раз - дякую.

— greenoldman

@greenoldman - як слід. Я теж сподіваюся, що хтось прийде з відповіддю з більш конкретними посиланнями.

— Теластин

Отже, це місце, де неможливість говорити як про вказівник, так і про вказівник комфортно і однозначно, це голова? Чорт сором.

— Дедуплікатор

"Люди стверджували, що він заплутаний код" - це все-таки правда, чи бачили ви деякі бібліотеки F #? Шум оператора. Наприклад quanttec.com/fparsec

— Den