Всім відомо, що, принаймні на C, ви використовуєте printfсімейство функцій для друку відформатованого рядка. І ці функції використовують знак відсотка ( %) для позначення початку специфікатора формату. Наприклад, %dзасоби для друку intта %uзасоби для друку unsigned int. Якщо ви не знайомі з тим, як printfфункціонують функції та формати заповнювачів, або вам просто потрібне оновлення, стаття у Вікіпедії - це гарне місце для початку.
Моє запитання: чи є особливо переконлива причина, чому це було спочатку або його слід обирати в майбутньому як специфікатора формату?
Очевидно, рішення було прийняте дуже давно (дуже ймовірно, що для попередника навіть мови С), і з тих пір воно було більш-менш "стандартним" (не тільки на С, але й у величезному масиві інших мов, які у різній мірі прийняли його синтаксис), тому далеко не пізно колись змінюватися. Але мені все одно цікаво, чи хтось має розуміння того, чому цей вибір, можливо, був зроблений в першу чергу, і чи все ще має сенс вибір, якщо розробляти нову мову з подібною функціональністю.
Наприклад, за допомогою C # (та іншого сімейства мов .NET) Microsoft прийняла дещо інше рішення щодо роботи функцій форматування рядків. Хоча певна ступінь безпеки типу може бути забезпечена (на відміну від реалізації printfв C), і тому не потрібно включати вказівку типу відповідного параметра, вони вирішили використовувати нульові індексовані пари фігурних дужок ( {}) як специфікатори формату, наприклад:
string output = String.Format("In {0}, the temperature is {1} degrees Celsius.",
"Texas", 37);
Console.WriteLine(output);
// Output:
// In Texas, the temperature is 37 degrees Celsius.
Документація String.Formatметоду містить більше інформації, як і ця стаття про складене форматування взагалі , але точні деталі є досить неважливими. Справа просто в тому, що вони відмовилися від давньої практики використання %для позначення початку специфікатора формату. Мова C може просто бути легко використані {d}і {u}, але це не так. У когось є якісь думки щодо того, чи має це рішення сенс ретроспективним і чи слід за ним виконувати нові реалізації?
Очевидно, що немає жодного символу, який не міг би бути вибраним, щоб він міг бути включений у саму рядок, але ця проблема досить добре вирішена вже за допомогою двох з них. Які ще міркування є актуальними?
{u}замість, %uале чи матиме це якусь істотну перевагу? Це здається значною мірою довільним вибором.
{}синтаксис, щоб люди, які навчаються C #, не почали вивчати нічого іншого? Мені дуже важко повірити, що це було головною, навіть якщо такою, частиною їх дизайнерського рішення. Чи можете ви якось створити резервну копію своєї заяви?
%форматування на користь чогось подібного до {}форматування .NET, оскільки останній пропонує більшу гнучкість.