Яка вигода від того, щоб оператор присвоєння повернув значення?

Я розробляю мову, яку я маю намір замінити як Javascript, так і PHP. (Я не можу бачити жодних проблем з цим. Це не так, як у будь-якої з цих мов є велика база встановлення.)

Однією з речей, яку я хотів змінити, було перетворення оператора присвоєння в команду присвоєння, видаляючи можливість використовувати повернене значення.

x=1;          /* Assignment. */
if (x==1) {}  /* Comparison. */
x==1;         /* Error or warning, I've not decided yet. */
if (x=1) {}   /* Error. */

Я знаю, що це означало б, що ті однолінійні функції, які так люблять люди С, більше не працюватимуть. Я подумав (маючи мало доказів, ніж мій особистий досвід), що переважна більшість разів це сталося, це було дійсно призначене для порівняння.

Або це? Чи є практичне використання зворотного значення оператора призначення, яке неможливо було б тривільно переписати? (Для будь-якої мови, яка має таке поняття.)

Технічно деякі синтаксичні цукру можна дотримуватися, навіть якщо його можна тривіально замінити, якщо він покращує читабельність якоїсь загальної операції. Але призначення-вираз не підпадає під це. Небезпека введення її замість порівняння означає, що її рідко застосовують (іноді навіть забороняють посібники зі стилів) і провокують подвійне використання, коли воно використовується. Іншими словами, переваги читабельності невеликі за кількістю та величиною.

Подивитись на існуючі мови, які роблять це, можливо, варто.

• Java і C # зберігають призначення виразом, але видаляють згадку, яке ви згадуєте, вимагаючи умов оцінювати булевим. Це, здається, працює добре, хоча люди час від часу скаржаться, що це усуває такі умови, як if (x)замість типу if (x != null)або if (x != 0)залежно від типу x.
• Python робить призначення замість виразу правильним оператором. Пропозиції щодо зміни цього періодично доходять до списку розсилки python-ідеї, але моє суб'єктивне враження полягає в тому, що це відбувається рідше і щоразу створює менше шуму в порівнянні з іншими "відсутніми" функціями, такими як цикли виконання, переключення, багаторядкові лямбда, тощо.

Однак, Python дозволяє використовувати один спеціальний випадок, зіставляючи кілька імен відразу: a = b = c. Це вважається твердженням, еквівалентним b = c; a = b, і його періодично використовують, тому його, можливо, варто додати і до вашої мови (але я б не впускав його, оскільки це доповнення повинно бути сумісним назад).

Чи є практичне використання зворотного значення оператора призначення, яке неможливо було б тривільно переписати?

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

Звичайні звичаї зазвичай роблять вирази компактними:

x = y = z;

має семантику в C # "перетворити z у тип y, призначити перетворене значення y, перетворене значення - це значення виразу, перетворити його у тип x, призначити x".

Але ми вже перебуваємо у царині невмілих побічних ефектів у контексті висловлювань, тому насправді дуже мало переконливої ​​користі для цього над

y = z;
x = y;

Аналогічно з

M(x = 123);

будучи стенограмою для

x = 123;
M(x);

Знову ж таки, у вихідному коді ми використовуємо вираз як для його побічних ефектів, так і для його значення, і ми робимо заяву, яка має два побічні ефекти замість одного. Обидва смердючі; намагайтеся мати один побічний ефект на кожне твердження та використовуйте вирази для їх значень, а не для їх побічних ефектів.

Я розробляю мову, яку я маю намір замінити як Javascript, так і PHP.

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

let x be 1;

Там, зробили. Або

x <-- 1;

а ще краще:

1 --> x;

Або ще краще ще

1 → x;

Немає жодного способу плутати когось із них x == 1.

Багато мов вибирають шлях складання заяви, а не виразу, включаючи Python:

foo = 42 # works
if foo = 42: print "hi" # dies
bar(foo = 42) # keyword arg

і Голанг:

var foo int
foo = 42 # works
if foo = 42 { fmt.Printn("hi") } # dies

Інші мови не мають призначення, а скоріше прив'язки, наприклад, OCaml:

let foo = 42 in
  if foo = 42 then
    print_string "hi"

Однак, letце сам вираз.

Перевага дозволу на призначення полягає в тому, що ми можемо безпосередньо перевірити повернене значення функції всередині умовного, наприклад, у цьому фрагменті Perl:

if (my $result = some_computation()) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}

Perl додатково привласнює декларацію лише до тієї умовної, що робить її дуже корисною. Він також попередить, якщо призначити всередині умовного, не оголошуючи там нову змінну - if ($foo = $bar)попередить, if (my $foo = $bar)не буде.

Здійснення призначення в іншому операторі, як правило, достатньо, але може спричинити проблеми з визначенням:

my $result = some_computation()
if ($result) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}
# $result is still visible here - eek!

Golang сильно покладається на значення повернення для перевірки помилок. Тому це дозволяє умовно приймати оператор ініціалізації:

if result, err := some_computation(); err != nil {
  fmt.Printf("Failed with %d", result)
}
fmt.Printf("We succeeded, and the result is %d\n", result)

Інші мови використовують систему типів, щоб заборонити небулеві вирази всередині умовного:

int foo;
if (foo = bar()) // Java does not like this

Звичайно, це не вдається при використанні функції, яка повертає булеву форму.

Зараз ми побачили різні механізми захисту від випадкового призначення:

• Заборонити призначення як вираз
• Використовуйте статичну перевірку типу
• Призначення не існує, у нас є лише letприв’язки
• Дозволити оператор ініціалізації, заборонити призначення інакше
• Заборонити призначення всередині умовного без декларації

Я класифікував їх за уподобанням переваг - призначення всередині виразів може бути корисним (і просто обійти проблеми Python, маючи явний синтаксис декларації та інший синтаксис аргументу з назвою). Але нормально їх заборонити, оскільки існує багато інших варіантів того ж ефекту.

Код без помилок важливіший за короткий код.

Ви сказали: "Я зрозумів (маючи мало доказів, ніж мій особистий досвід), що переважна більшість разів це сталося, це було дійсно призначене для порівняння".

Чому б не виправити проблему?

Замість = для присвоєння та == для тесту на рівність, чому б не використовувати: = для присвоєння та = (або навіть ==) для рівності?

Дотримуйтесь:

if (a=foo(bar)) {}  // obviously equality
if (a := foo(bar)) { do something with a } // obviously assignment

Якщо ви хочете ускладнити програмісту помилку в призначенні рівності, тоді зробіть це складніше.

У той же час, якщо ви дійсно хотіли б вирішити проблему, ви видалили б череп C, який стверджував, що булевики були просто цілими числами із заздалегідь заданими символічними назвами цукру. Зробіть їх взагалі різного типу. Тоді, замість того, щоб сказати

int a = some_value();
if (a) {}

ти змушуєш програміста написати:

int a = some_value();
if (a /= 0) {} // Note that /= means 'not equal'.  This is your Ada lesson for today.

Справа в тому, що присвоєння оператора - це дуже корисна конструкція. Ми не ліквідували леза, тому що деякі люди різали себе. Натомість король Жиллет винайшов безпечну бритву.

Насправді, щоб відповісти на це питання, так, це є чимало застосувань цього, хоча вони дещо ніші.

Наприклад, на Java:

while ((Object ob = x.next()) != null) {
    // This will loop through calling next() until it returns null
    // The value of the returned object is available as ob within the loop
}

Альтернатива без використання вбудованого призначення вимагає obвизначеного за межами області циклу та двох окремих кодів, що викликають x.next ().

Вже було сказано, що ви можете призначити кілька змінних за один крок.

x = y = z = 3;

Такі речі є найбільш поширеними, але творчі програмісти завжди придумують більше.

Оскільки ви маєте скласти всі правила, чому тепер дозволити призначенню повертати значення, а просто не дозволяти призначенню в умовних кроках? Це дає вам синтаксичний цукор, щоб спростити ініціалізацію, одночасно запобігаючи поширеній помилці кодування.

Іншими словами, зробіть це законним:

a=b=c=0;

Але зробіть це незаконним:

if (a=b) ...

За його звуками ви на шляху створення досить суворої мови.

Зважаючи на це, змушуючи людей писати:

a=c;
b=c;

замість:

a=b=c;

може здатися вдосконаленням, щоб люди не робили:

if (a=b) {

коли вони мали намір робити:

if (a==b) {

але врешті-решт подібні помилки легко виявити та попередити про те, чи є вони юридичним кодексом.

Однак є ситуації, коли роблять:

a=c;
b=c;

це не означає

if (a==b) {

буде правдою.

Якщо c насправді є функцією c (), то вона може повертати різні результати кожного разу, коли вона викликається. (це також може бути обчислювально дорогим ...)

Так само, якщо c - вказівник на апаратне забезпечення, відображене на пам'ять, то

a=*c;
b=*c;

вони, ймовірно, будуть різними, а також можуть мати електронні ефекти на апаратне забезпечення при кожному прочитанні.

Існує безліч інших перестановок із апаратним забезпеченням, де потрібно точно визначити, з яких адрес пам'яті читаються, записуються до та під певні обмеження часу, коли виконання декількох призначень в одному рядку є швидким, простим і очевидним, без тимчасових ризиків, які ввести тимчасові змінні

Найбільша користь для моєї присвоєння завданням є вираз - це те, що це дозволяє вашій граматиці бути простішою, якщо однією з ваших цілей є те, що "все є вираженням" - зокрема, LISP.

У Python цього немає; він має вирази та висловлювання, присвоєння є заявою. Але оскільки Python визначає lambdaформу як єдиний параметризований вираз , це означає, що ви не можете призначити змінні всередині лямбда. Часом це незручно, але не є критичним питанням, і це є єдиним недоліком мого досвіду в тому, щоб мати завдання - це заява в Python.

Один із способів дозволити призначенню, а точніше ефекту присвоєння, бути вираженням, не вводячи потенціал if(x=1)нещасних випадків, який має С, - використовувати letконструкцію, подібну до LISP , таку, (let ((x 2) (y 3)) (+ x y))яку, можливо, у вашій мові оцінюють як 5. Використовуючи letцей спосіб, технічно не потрібно взагалі призначати свою мову, якщо ви визначаєте letяк створення лексичного простору. Визначений таким чином, letконструкція може бути складена так само, як побудова та виклик вкладеної функції закриття з аргументами.

З іншого боку, якщо вас просто стосується if(x=1)справи, але ви хочете, щоб призначення було виразом, як у С, можливо, достатньо просто вибрати різні лексеми. Призначення: x := 1абоx <- 1 . Порівняння: x == 1. Синтаксична помилка: x = 1.

Я знаю, що це означало б, що ті однолінійні функції, які так люблять люди С, більше не працюватимуть. Я подумав (маючи мало доказів, ніж мій особистий досвід), що переважна більшість разів це сталося, це було дійсно призначене для порівняння.

Справді. Це нічого нового, всі безпечні підмножини мови С вже зробили такий висновок.

MISRA-C, CERT-C і так далі всі заборони присвоювати всередині умов просто тому, що це небезпечно.

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

Крім того, такі стандарти також застерігають від написання коду, який спирається на порядок оцінювання. Кілька завдань в одному рядкуx=y=z; є таким випадком. Якщо рядок з декількома призначеннями містить побічні ефекти (викличні функції, доступ до змінних змінних тощо), ви не можете знати, який побічний ефект виникне першим.

Між оцінкою операндів немає точок послідовності. Тож ми не можемо знати, чи є субекспресіяy оцінюється до чи після z: це не визначена поведінка у C. Таким чином, такий код є потенційно ненадійним, непереносним та невідповідним згаданим безпечним підмножинам C.

Рішенням було б замінити код на y=z; x=y; . Це додає бал послідовності та гарантує порядок оцінювання.

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