Здравствуйте, VladD2, Вы писали:

VD>Я отвечу на твой вопрос сразу после того как ты скажешь какое он имеет отношение к данному обсуждению?
Очень простой — насколько оправдано работать со средствами, которые не дают возможности прямого вмешательства в сгенерированный код.
В смысле "один раз сгенерировал, но потом поддерживай изменения вручную", а не "перегенерировать на каждый билд".

VD>Лучше, на всякий случай, поясни какое отношение имеет вопрос объем каких-то там работ к возможности подправить макрос и вставить в него те же partial-ы которые позволят вручную что-то там подправить.
Вопрос принципиальной возможности стоит потому, что мне непонятно, с чего это вдруг считается, что генерациями партиалов можно решить любую one-off проблему.
На мой взгляд, это слишком смелое утверждение. Возможно, оно и справедливо, но доказательства я пока не увидел.
А после того, как это (применимость partial method для абсолютно любого частного случая), будет неплохо сравнить затраты усилий на корректное добавление этого метода в макрос Nemerle, с затратами усилий на ручную правку единичной проблемы в сгенерированном коде.
Чисто чтобы понять, что лучше.

Здравствуйте, Ikemefula, Вы писали:
I>За счет чего проще объяснять ?
За счет того, что она работает изоморфно String.Concat. То есть более убогую функциональность трудно себе вообразить. Странно, что ее сравнивают со String.Format, потому что сравнивать нужно с

"Output: " + a.ToString()

Здравствуйте, VladD2, Вы писали:

VD>Согласен. Скажу больше. У формат-стринга есть еще одно приемущество (в некоторых случаях) — она позволяет менять формат в рантайме.

VD>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:
VD>

VD>$"Rum-Coke: $(F2(10 / 3))"
VD>

А знак доллара выведется? Или он должен быть частью функции форматирования?

VD>Или тупо воспользоваться форматом.
Хм. А ты можешь пояснить, почему строки сделаны именно так? Как аналог перла?
Потому что мне, к примеру, кажется, что для внедрения на рынок дотнета выгоднее было бы починить проблемы String.Format.
Самый хомячковый вариант — заменить номера аргументов на сами выражения.
Тогда бы работало, скажем, вот так:

Console.WriteLine($"Rum-Coke: {price:2}");

Как бы и волки сыты, и яйцы целы. В том смысле, что MSDN годами воспитывает людей пользоваться форматными строками, и грех не использовать эти наработки.
(Я намеренно убрал выражение из строки — именно потому, что в реальных случаях скорее всего речь будет идти о биндингах к переменным)

VD>В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.
А без намёка на мою недалекость можно было обойтись?

Здравствуйте, Undying, Вы писали:
U>Можно вопрос? В своих приложениях string.Format("Некая константа: {0}", obj) я пишу по большим праздникам, зато очень часто пишу TraceHlp2.AddMessage("Некая константа: {0}", obj). Можно объяснить как сплайс-строка позволит мне записать TraceHlp2.AddMessage лучшим образом?
Очевидно, тебе достаточно заменить все аргументы AddMessage одним вхождением сплайс-строки.

Здравствуйте, IT, Вы писали:

VD>>Есть, пользуются... не спорю. Только это уродство.
IT>Что-то из тебя какой-то неадекват попёр.

Или из тебя. Давай лучше по делу говорить.

VD>>>>Изменение модели.
IT>>>Какой модели?
VD>>Любая генерация кода подразумевает, что есть модель описывающая базовые данные по которой генерируются частности.

IT>Генератор — это прежде всего инструмент. В качестве инструмента, я могу, например, взять редактор кода и одним глазом подглядывая в SQL на структуру таблицы перенабить эту таблицу себе в код. Дале я буду поддерживать полученный класс в ручную. Как я понимаю — это правильный путь.

Это экстенсивный, а значит не правильный путь. Не надо брат на себя задачи с которыми компьютер справится лучше человека.

IT>Но если я вместо ручной начальной набивки напущу на эту таблицу генератор, то это уже уродство. Так что ли? Но ведь ты не найдёшь ни одного различия между этими классами. Так какая разница?

Это нехорошо по любому. Но когда ты создаешь генератор, ты как бы уже уверен, что ручное решение задачи не эффективно. К тому же смешивание подходов до добра не доведет.

В общем, за пределами задач визарда я подобного подхода не вижу. А визард — это обычно очень примитивная мета-программа.

Здравствуйте, Undying, Вы писали:

U>Т.е. ради несколько более оптимального решения небольшой задачи (вывода форматированной строки) в язык вводится принципиально новая конструкция.

Оно принципиально новое только для Блаба который не знает о существовании других языков (например, PHP).
Но в общем — да — в язык добавляется конструкция увеличивающая контроль, упрощающая восприятие и написание сложного кода форматирующего текст. В итоге это очень сильно упрощает работу со строками которая, как не странно занимает весьма заметное место в любой программе.

VD>>В прочем, одно преимущество у стрин-формата есть — они позволяет менять строку формата в рантайме. Сплайс-строка контролируется во время компиляции.

U>При этом новый способ решения задачи более узкий, чем старый, часть задач, которые можно было решать с помощью string.Format, с помощью сплайс-строк решить не удастся.

Именно так. Только кто из них старый, а кто новый еще надо разобраться.
Специализированное решение почти всегда лучше универсального. За контроль компилятора и максимально эффективный код приходится платить отсутствием некоторых динамических фич. Это полностью аналогично сравнению динамических языков со статическими.

U>Соответственно string.Format все равно придется учить и о нем помнить.

А вот это как раз не обязательно. Не как-то принципиальных проблем чтобы не создать динамическую версию $-строк.
Сплайсы могут вычисляться на стадии компиляции и их вычисление помещаться в переменные. А строка форматирования может меняться динамически или читаться из файла ресурсов. Все это лишь вопросы реализации.

U>В мэйнстримовском языке не должно быть 25 способ решения задачи, позволяющих каждый случай решить оптимальным образом.

Это не правад. В любом языке есть несколько способов сделать одно и то же. Скажем чтобы отформатировать стороку в C# можно использовать весьма разные механизмы. Тот же .ToString(с_параметрами) никто не отменял.
Другое дело, что практика обычно выбирает более удобные. Что касается немерла, то string.Format в нем обычно используют только те кто только что пересел с C#. Со временем народ переходит на использование $-строк.

U>Мэйнстримовский язык должен содержать минимальное количество способов решения задач, позволяющих решить 99,9% задач качественным (но не обязательно оптимальным) способом.

Дык минимальное не означает одно. Правда? Собственно так оно и есть на самом деле. Есть удобный, эффективный, наглядный способ форматирования строк применяемое в 99% случаев и еще парочка менее удобных, но более гибких.

U>Новые способы решения задач, несколько более оптимальные, но имеющие какие-то недостатки и/или неспособные полностью вытеснить старые способы решения тех же задач должны добавляться в мэйнстримовский язык с большой осторожностью. К сожалению похоже даже разработчики шарпа перестали это понимать.

Разрабочики Шарпа как раз делают полезное дело. Жаль, только, что они не продумывают свои действия с нуля, а идут итеративным путем.

В прочем, может быть я не понимаю о чем идет речь. Поясни, что тебе не нравится в Шарпе.

Здравствуйте, Sinclair, Вы писали:

VD>>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:
VD>>

VD>>$"Rum-Coke: $(F2(10 / 3))"
VD>>

S>А знак доллара выведется? Или он должен быть частью функции форматирования?

Вот это:
$(F2(10 / 3))
сплайс. Все что заключено в скобки — это выражения. F2 — это простая функция (гипотетическая, ее реально нет). Она принимает на вход double и возвращает строку. С тем же успехом можно было бы использовать инлайном ToSring("00"), но это было бы длиннее двухбуквенного формата.

VD>>Или тупо воспользоваться форматом.
S>Хм. А ты можешь пояснить, почему строки сделаны именно так? Как аналог перла?

Скорее как аналог PHP или Руби. Пояснять мне не с руки, так как не я это дело придумал. Но предположить могу.
С одной стороны в языке уже есть $-нотация квази-цитирования применяемая для композиции и декомпозиции кода в макросах. Это делает такой подход вполне естественным.
С другой стороны есть такие, доказавшие свое удобство, языки как PHP или Руби и рубки где работа со строками сделана сходным образом. Придумать что-то более интуитивно понятное уже будет весьма не просто.

S>Потому что мне, к примеру, кажется, что для внедрения на рынок дотнета выгоднее было бы починить проблемы String.Format.
S>Самый хомячковый вариант — заменить номера аргументов на сами выражения.
S>Тогда бы работало, скажем, вот так:
S>

S>Console.WriteLine($"Rum-Coke: {price:2}");
S>

S>Как бы и волки сыты, и яйцы целы. В том смысле, что MSDN годами воспитывает людей пользоваться форматными строками, и грех не использовать эти наработки.

Это практически синтаксис Руби и новой версии Питоне (если не ошибаюсь). Разницы почти никакой. Только синтаксические различия. Можно сделать и такой макрос.

Что же касается МСДН-а, то сколько я не работал с дотнетом все время для меня было проблемой найти описание формата. Он не интуитивен и при этом очень плохо ищется в МСДН. Так что не думаю, что это реально стало бы приемуществом.
Мы думали о введении формата через двоеточие. Но до реализации руки так и не дошли. Ну, и потребности на практике особой нет.

S>(Я намеренно убрал выражение из строки — именно потому, что в реальных случаях скорее всего речь будет идти о биндингах к переменным)

Случаи бывают разные. Кроме того $-нотация поддерживает и работу со списками. Это очень удобно, но при этом иногда нужно задавать резделители и функцию конвертации. Вот продвинутый пример использования сплай-строк:

def attributs = ["public", "static"];
def methodName = "SomeMethod";
def parameters = [("param1", "int"), ("param2", "string")];
def retType = "double";

WriteLine();
WriteLine("Сигнатруа в C#-стиле:");
WriteLine($<# ..$(attributs; " ") $retType $methodName(..$(parameters; ", "; (n, t) => $"$t $n")); #>);

WriteLine();
WriteLine("Сигнатруа в Nemerle-стиле:");
WriteLine($<# ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n : $t")) : $retType; #>);

WriteLine();
WriteLine("Сигнатруа в VB-стиле:");
WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>);

Он выводит на консоль:

Сигнатруа в C#-стиле:
 public static double SomeMethod(int param1, string param2);

Сигнатруа в Nemerle-стиле:
 public static SomeMethod(param1 : int, param2 : string) : double;

Сигнатруа в VB-стиле:
 Function public static SomeMethod(param1 as int, param2 as string) as double

Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.

VD>>В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.
S>А без намёка на мою недалекость можно было обойтись?

А я не на тебя намекал. Ты как раз все оцениваешь совершенно адекватно, на мой взгляд.

Здравствуйте, Lloyd, Вы писали:

L>Про "макры которые не просто локализуют строки"?
L>Тогда переформулирую вопрос. Если нам понадобилось локализовать строку в $ нотации, нужно ли ее переделывать в "локализуемые" строки?
L>А локализуемые строки будут поддерживать $-нотацию? А если надо заменить часть этой строки, предусмотрен ли механизм, аналогичный "{0}"?

Все что нужно сделать — это заменить "$" на "L". Далее при компиляции автоматически создается файл куда "выкидываются" все строковые литералы где вместо сплайсов стоят некие заменители вроде любимых тобою "{0}".

Здравствуйте, VoidEx, Вы писали:

VD>>Лучше поупражняйся сам и опиши чем лучше делать наоборот. Все что ты выкинишь из своих доказательств и будет ответом на твои слова.

VE>Нет нет. "Наоборот" — это уже будет не доказательство. За что люблю детские вопросы типа "зачем", "почему", потому что они раскрывают, что тот, кто говорит, сам ничего не понимает, если до сути докопаться.

Детям практически нельзя ничего объяснить серьезно. Как правильно заметил IT детям говорят, что "солнышко пошло спать", а когда они подрастут и поумнеют, им объясняют, что земля крутится вокруг солнца. За-то у детей есть доверие к взрослым. И если ребенку сказали что-то, то он это принимает это на веру.
Тут же получается глупая ситуация. Есть люди которые не в состоянии что-то воспринять по причине отсутствия базы и опыта, но на слово они не верят и требуют каких-то доказательств.

Ребята. Вам ничего доказать нельзя по причине отсутсвия базы. Идите наберите эту базу, а потом приходите и вам не придется ничего доказывать. Достаточно будет просто объяснить.

VE>Вот ты уверен, что лучше. Абсолютно уверен. Но не знаешь, почему. Для такого казалось бы очевидного утверждения нужно доказать, что хорошие спецы с новой технологией в целом обойдутся дешевле тысячи блабов. А в жизни куча примеров и первого, и второго.

Я уже не уверен в том что помню о чем я говорил. Так как вся тема состоит из тысяч таких вот просьб обосновать. При этом свои абсурдные утверждения наши оппоненты обосновывать не считают нужным.

Разговор это бессмысленный и без полезный.

Здравствуйте, VladD2, Вы писали:

L>>Тогда переформулирую вопрос. Если нам понадобилось локализовать строку в $ нотации, нужно ли ее переделывать в "локализуемые" строки?
L>>А локализуемые строки будут поддерживать $-нотацию? А если надо заменить часть этой строки, предусмотрен ли механизм, аналогичный "{0}"?

VD>Все что нужно сделать — это заменить "$" на "L".

Ты имеешь в виду префикс строки или сплайса?

VD>Далее при компиляции автоматически создается файл куда "выкидываются" все строковые литералы где вместо сплайсов стоят некие заменители вроде любимых тобою "{0}".

Здравствуйте, yumi, Вы писали:

VD>>Писать мета-код на С++ очень сложно. Понять его тоже весьма сложно. От того писать его могут единицы. Факт? Факт!

Y>Твоими бы да устами... А то ведь пишут, читают Александреску и пишут...

А сколько процентов человек то это делает?
На С++ пишут миллионы, но только еденицы используют техники предложенные Александреску. И -ами их обзывают как раз те, кто понимает, что можно сделать все тоже самое но значительно проще. А большинство просто тупо не понимают, что они там делают и даже не могут оценить, так как они используют не весь С++, а его часть. Они думают на этой части и от того не в силах понять, что же там за закорючки пишут эти "гурья".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:

VD>>>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:
VD>>>

VD>>>$"Rum-Coke: $(F2(10 / 3))"
VD>>>

S>>А знак доллара выведется? Или он должен быть частью функции форматирования?

VD>Вот это:
VD>$(F2(10 / 3))
VD>сплайс. Все что заключено в скобки — это выражения. F2 — это простая функция (гипотетическая, ее реально нет).
Это я понимаю. Просто мне кажется несколько избыточным требовать на каждый чих писать отдельную функцию. Это с точностью до наоборот противоречит идее сделать запись более компактной.
Кроме того, такая функция затрудняет понимание. Стандартные форматные строки входят в курс молодого бойца, и мы имеем права требовать их понимания от любого стажера. А вот все эти F2; FX и прочие нужно пойти и разобрать по исходнику, потому что документации на них нет, а имена — коротки до нечитаемости.

VD>Скорее как аналог PHP или Руби. Пояснять мне не с руки, так как не я это дело придумал. Но предположить могу.
VD>С одной стороны в языке уже есть $-нотация квази-цитирования применяемая для композиции и декомпозиции кода в макросах. Это делает такой подход вполне естественным.
VD>Это практически синтаксис Руби и новой версии Питоне (если не ошибаюсь). Разницы почти никакой. Только синтаксические различия. Можно сделать и такой макрос.
VD>Что же касается МСДН-а, то сколько я не работал с дотнетом все время для меня было проблемой найти описание формата. Он не интуитивен и при этом очень плохо ищется в МСДН. Так что не думаю, что это реально стало бы приемуществом.
Во-первых, теперь это починили. Ссылка на документацию по формату лежит прямо на странице string.Format.
Во-вторых, зацени: это не твоя проблема. Парни из майкрософт ежегодно вкладывают тучу денег в поддержание вот этой документации. Литературы по шарпу — море разливанное. Если бы ты сдавал экзамен на MCSD по нему (как это делают все индусы), то у тебя бы было 90% знание этих форматов и знание, где именно в MSDN они лежат.
VD>Мы думали о введении формата через двоеточие. Но до реализации руки так и не дошли. Ну, и потребности на практике особой нет.
Тут вопрос открытый — пока что user base очень мала; рассчитывать на то, что все хорошие фичи будут запрошены пользователями пока смело. Нет практики — нет потребности; нет потребности — нет реализации; нет реализации — нет практики. Ты же вот сам пишешь "ну или использовать тупой Format". Возможно, это underestimated feature, которая всем была бы мегаполезна, будь реализована в полном виде.
(Дисклаймер: может быть, и не была бы. Я не имею права выступать за всё сообщество.)

VD>Случаи бывают разные. Кроме того $-нотация поддерживает и работу со списками.
Прикольно, что ни в одной ссылке, приведенной про нее, это не написано. Или приводимые тобой примеры — частный случай выражений?

VD>Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.
Ну, с учетом того, что у меня всегда в загашнике лежит функция string Join(this IEnumerable<T> source, string separator, Function<T, string> converter), всё не так страшно, как ты описываешь
Это сведется собственно к

WriteLine("Function {0} {1}({2})", attributes.Join(" "), parameters.Join(", ", Parameter p => string.Format("{0} as {1}", p.n, p.t)));

не слишком много оверхеда по сравнению с

WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>);

Но ты, конечно же, прав. Твой вариант компактнее и нет риска ошибиться с номером аргумента.

Хотя на самом деле — фишка в том, что разработчики дотнетного форматирования уже проделали большую предварительную работу.
И где-то я встречал статью про user-defined format strings, которые позволяют вообще отжигать не-подетски. Если то, что я смутно помню — правда, то можно было бы замутить реализацию приведенного тобой конвертера списков в строку на основе всё той же format string технологии, без хардкода.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Sinclair, Вы писали:

S>>

S>>Console.WriteLine("Rum-Coke: ${0:F2}", 10/3);
S>>

IT>

IT>$"Rum-Coke: $((10/3).ToString(see MSDN for details))";
IT>

А, ну то есть собственно

$"Rum-Coke: \$$((10/3).ToString(\"F2\"))";

Это если я правильно понял кошерный способ заэкранировать доллар — на всякий случай напомню, что в шарпе он не спецсимвол, а является частью литерала.
Что приводит к выводу на консоль "Rum-Coke: $3.33".
Что ж, негусто.
IT>Но можно макру допилить для поддержки форматирования.
Вот это уже радует. Самый, имхо, кошерный способ был бы как раз через :, и дальше делегировать всё стандартной библиотеке.
Единственное, с чем в ней будет плохо — это с компайл-тайм верификацией типов аргументов. То есть запросто можно будет попытаться дату вывести в формате валюты.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:

VD>>Я отвечу на твой вопрос сразу после того как ты скажешь какое он имеет отношение к данному обсуждению?
S>Очень простой — насколько оправдано работать со средствами, которые не дают возможности прямого вмешательства в сгенерированный код.
S>В смысле "один раз сгенерировал, но потом поддерживай изменения вручную", а не "перегенерировать на каждый билд".

Это вопрос не относится к обсуждаемому, и задавать его на мой же вопрос было весьма некорректно.

На мой взгляд, править в ручную сгенерированный код — плохо. Но еще хуже поддерживать вручную код который можно сгенерировать по модели. Это явный признак какого-то просчета в дизайне приложения. Или генератор слаб (он мутный, его сложно поддерживать и развивать, он создан без подобающих средств), или модель выбрана не верно, или программист не соображает, что он делает.

VD>>Лучше, на всякий случай, поясни какое отношение имеет вопрос объем каких-то там работ к возможности подправить макрос и вставить в него те же partial-ы которые позволят вручную что-то там подправить.
S>Вопрос принципиальной возможности стоит потому, что мне непонятно, с чего это вдруг считается, что генерациями партиалов можно решить любую one-off проблему.

Наверно потому, что ты можешь любую проблему решить вручную. А раз так, то тебе только остается дать возможность вписывать рукописаный код туда куда тебе нужно.

В прочем, на практике, в случае макросов, обычно или вводятся дополнительные параметры (которые можно скрыть задав им значения по умолчанию) или подправляется генерируемый код.

S>На мой взгляд, это слишком смелое утверждение. Возможно, оно и справедливо, но доказательства я пока не увидел.

А как тебе это доказать? Доказать, что это возможно, можно просто приведя пример. А доказать, что это покрывает 100% случаев неизвестно чего...

S>А после того, как это (применимость partial method для абсолютно любого частного случая), будет неплохо сравнить затраты усилий на корректное добавление этого метода в макрос Nemerle, с затратами усилий на ручную правку единичной проблемы в сгенерированном коде.
S>Чисто чтобы понять, что лучше.

Проведи исследования и опубликуй результат. Именно так и делается в научных кругах. В прочем, многих и это не устраивает. Скажем алгебраические типы, сопоставление с образцом, квази-цитирование и прочие составляющие Немерле описаны в научных работах где доказывается их эффективность и т.п. Но толку с этого мало.

Здравствуйте, Lloyd, Вы писали:

VD>>Все что нужно сделать — это заменить "$" на "L".

L>Ты имеешь в виду префикс строки или сплайса?

Префикс строки.

Здравствуйте, VladD2, Вы писали:

L>>Ты имеешь в виду префикс строки или сплайса?

VD>Префикс строки.

А префикс сплайса в L-строках все так же продолжит работать как и в $-строках?

Здравствуйте, Sinclair, Вы писали:

S>Это я понимаю. Просто мне кажется несколько избыточным требовать на каждый чих писать отдельную функцию. Это с точностью до наоборот противоречит идее сделать запись более компактной.

Дык если бы каждый чих этого требования, то проблему бы давно решили написав набор стандартных функций или введя синтаксис аналогичны сринг-формату. На на практике потребность фоматировать даблы столь редка, что о ней и говорить не приходится. К тому, же всегда можно настроить все через культуру. Это зачастую снимает много проблем.

S>Кроме того, такая функция затрудняет понимание. Стандартные форматные строки входят в курс молодого бойца, и мы имеем права требовать их понимания от любого стажера. А вот все эти F2; FX и прочие нужно пойти и разобрать по исходнику, потому что документации на них нет, а имена — коротки до нечитаемости.

Все эти F2 и FX действительно затрудняют понимание и никакими курсами тут не поможешь. Я вроде уже боец не молодой, но запомнить эту ересь я не могу. А функция затрудняет понимание нее больше чем знаки форматирования. Скажу больше, функция может содержать описание которое будет видно из подсказки (хинта) в IDE. Это решает проблему чтения, в отличии от срок форматирования.

S>Во-первых, теперь это починили. Ссылка на документацию по формату лежит прямо на странице string.Format.

А на странице с WriteLine? Плюс даже найдя это описание раньше было не просто разобраться в той жути которая там написана.

S>Во-вторых, зацени: это не твоя проблема.

Не. Это проблема МС, твоая или еще кого-то но не мая. Я умею вызвать функции . Мне ничего не стоит добавить одну функцию в проект и вызывать ее когда мне это будет нужно.

S>Парни из майкрософт ежегодно вкладывают тучу денег в поддержание вот этой документации. Литературы по шарпу — море разливанное. Если бы ты сдавал экзамен на MCSD по нему (как это делают все индусы), то у тебя бы было 90% знание этих форматов и знание, где именно в MSDN они лежат.

Значит мало вкладывают. Когда там добавили ссыклу в стрин.Формат?
Ладно, вопрос риторический. Я считаю, что решения должны быть интуитивно понятными. Тогда и документацию смотреть не потребуется. А формат в старин-формат сдалан в лучших традициях перла. Никакой логики, одни двухбуквенные согращения. Но за-то народ привыкший к этому дерьму и не видевший ничего более разумного начинает с пеной у рта отстаивать это уродство.

Кстати, одно из соображений почему мы не сделали формат аналогичный стринг-форматному как раз и была полная непонятность этого формата. А ведь еще в 6-ом Васике вроде как были весьма интуитивно понятные средства форматирования.

VD>>Мы думали о введении формата через двоеточие. Но до реализации руки так и не дошли. Ну, и потребности на практике особой нет.
S>Тут вопрос открытый — пока что user base очень мала; рассчитывать на то, что все хорошие фичи будут запрошены пользователями пока смело. Нет практики — нет потребности; нет потребности — нет реализации; нет реализации — нет практики. Ты же вот сам пишешь "ну или использовать тупой Format". Возможно, это underestimated feature, которая всем была бы мегаполезна, будь реализована в полном виде.

Делать хорошие фичи из соображений "чтобы було, а то вдруг кто спросит" не просто смело, а архи-глупо.

Интересно, что в комьюнити Немерла все с точностью до наоборот по сравнению с МС. У нас люди сами пытаются сделать то, что нужно им и передают результаты труда в общее пользование.

Но, конечно, если люди начнут массово просить ввести ту или иную фичу, то ее обязательно добавят. Но реализует ее, возможно, один из пользователей. Так уже было много раз.

VD>>Случаи бывают разные. Кроме того $-нотация поддерживает и работу со списками.
S>Прикольно, что ни в одной ссылке, приведенной про нее, это не написано. Или приводимые тобой примеры — частный случай выражений?

Это не правда. Ты просто плохо смотрел. Вот, например.

VD>>Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.
S>Ну, с учетом того, что у меня всегда в загашнике лежит функция string Join(this IEnumerable<T> source, string separator, Function<T, string> converter), всё не так страшно, как ты описываешь
S>Это сведется собственно к
S>

S>WriteLine("Function {0} {1}({2})", attributes.Join(" "), parameters.Join(", ", Parameter p => string.Format("{0} as {1}", p.n, p.t)));
S>

S>не слишком много оверхеда по сравнению с
S>

S>WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>); 
S>

S>Но ты, конечно же, прав. Твой вариант компактнее и нет риска ошибиться с номером аргумента.

S>Хотя на самом деле — фишка в том, что разработчики дотнетного форматирования уже проделали большую предварительную работу.
S>И где-то я встречал статью про user-defined format strings, которые позволяют вообще отжигать не-подетски. Если то, что я смутно помню — правда, то можно было бы замутить реализацию приведенного тобой конвертера списков в строку на основе всё той же format string технологии, без хардкода.

Здравствуйте, Sinclair, Вы писали:

VD>>Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.
S>Ну, с учетом того, что у меня всегда в загашнике лежит функция string Join(this IEnumerable<T> source, string separator, Function<T, string> converter), всё не так страшно, как ты описываешь
S>Это сведется собственно к
S>

S>WriteLine("Function {0} {1}({2})", attributes.Join(" "), parameters.Join(", ", Parameter p => string.Format("{0} as {1}", p.n, p.t)));
S>

S>не слишком много оверхеда по сравнению с
S>

S>WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>); 
S>

Гы. Ты уже допустил ошибку. Имя метода ты пропустил . А ты еще додумался сделать высокоуровневый Join. Большинство выходцев из серых масс вообще бы цикл залудило и стало бы использовать StringBuilder.

S>Но ты, конечно же, прав. Твой вариант компактнее и нет риска ошибиться с номером аргумента.

Заметь еще что:
1. В нем проще разобраться так как не надо выискивать соответствие плэйсхолдеров параметрам. Уже в таком простом примере я лично путаюсь. А что будет в более сложном?
2. Я пользовался исключительно стандартными для языка средствами (макрос входит в стандартную библиотеку, а твоя функция — нет).
3. Я использую декларативное описание паттерна "печать списка", а ты вынужден приводить ее реализацию.
4. В результате выполнения моего кода получится максимально эффективный код. Причем тебе не придется об этот заботиться.

Не так мало, для простого примера. Согласен?

S>Хотя на самом деле — фишка в том, что разработчики дотнетного форматирования уже проделали большую предварительную работу.
S>И где-то я встречал статью про user-defined format strings, которые позволяют вообще отжигать не-подетски. Если то, что я смутно помню — правда, то можно было бы замутить реализацию приведенного тобой конвертера списков в строку на основе всё той же format string технологии, без хардкода.

Мне всегда больше нравилось слово "есть", чем слова "можно было бы".

Кайф макроса в том, что в отличии от хардкода его можно менять как обычную функцию. Так что если ты мне покажешь решение более элегантное, то я его всегда смогу реализовать.

Здравствуйте, Sinclair, Вы писали:

S>А, ну то есть собственно
S>

S>$"Rum-Coke: \$$((10/3).ToString(\"F2\"))";
S>

Так пишут начинающие немерлисты переходящие с C#. Продвинутые обычно пишут так:
$<#Rum-Coke: $$$((10/3).ToString("F2"))#>
а еще более продвинутые так:
def money(value) { "$" + value.ToString("F2") }
...
$"Rum-Coke: $(money(10/3))"

S>Это если я правильно понял кошерный способ заэкранировать доллар — на всякий случай напомню, что в шарпе он не спецсимвол, а является частью литерала.

В немерле он тоже не специмвол. Так что экрнировать его в этом случае не надо. Если же тебе нужно вывести доллар внутри сплайс-строки, то его просто нужно удвоить. Кроме того можно еще написать $("$").

S>Что приводит к выводу на консоль "Rum-Coke: $3.33".
S>Что ж, негусто.

Я не очень понимаю смысла поиска фатальных недостатков. Ну, нашел ты один случай который который создал тебе трудности. И что из этого? Не уподобляйся некоторым, не делай выводы из придуманной же собой гипотетической ситуации. Подумай лучше насколько часто такое может случаться?

IT>>Но можно макру допилить для поддержки форматирования.
S>Вот это уже радует. Самый, имхо, кошерный способ был бы как раз через :, и дальше делегировать всё стандартной библиотеке.

А на мой взгляд как раз формат этот и есть перлоподобный ужас.

S>Единственное, с чем в ней будет плохо — это с компайл-тайм верификацией типов аргументов. То есть запросто можно будет попытаться дату вывести в формате валюты.

А в чем тут проблема то? Вставить в макру средство проверки типов аргументов не проблема. Например, макра sprintf аналогичная С-шному sprintf-фу проверяет типы аргументов и выдает сообщения об ошибках во время компиляции. Вот если ты как-нить object передашь, тогда другое дело. Но его использование можно и запретить.

Здравствуйте, Lloyd, Вы писали:

L>А префикс сплайса в L-строках все так же продолжит работать как и в $-строках?

Да. Но надо понимать, что это макрос, так что можно сделать так как тебе нравится.