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

D>>То проект не соберётся и заставит исправлять ошибки. Тогда как, если поменялись местами аргументы одинакового типа, всё будет молчать.

SD>Что, и даже тесты не упадут?

А что, их, типа, писать все умеют (и хотят) (и хотят уметь)?

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

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

D>>Чисто теоритически, язык может предоставить опции по совмещению подходов, как питон, например.
S>Чисто практически, C# такие опции тоже предоставляет.
S>Речь-то шла не о том, что есть в языке, а чего нету. А о том, что удобнее использовать.

Ну а я о чём? Когда удобнее и понятнее именованные параметры — тогда их и используем. Когда неудобно — не используем :xz
Код, ведь, для читателей пишется. Вот об этом и надо думать, а не о фанатизме применения идиом по религиозным причинам.

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

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

E>>Если в функции 40 параметров, то
E>>во-первых, с функцией явные проблемы
E>>во-вторых, для передачи параметров используют один объект с 40 полями

GIV>ага, а объект иммутабл нужен, упс у нас конструктор с 40 параметрами )
GIV>функции с 40 параметрами по опыту и делают часто объект с 40 полями
GIV>и там еще у большинства дефолтные значения.
GIV>вполне норм, больших проблем с этим нет.

Или не нужно что бы было иммутабл, если это единоразовая передача параметров.
В Фабрику, например.
Да и не редко такие объекты конструируются не руками.
Другое дело, что 40 параметров это само по себе не нормально, особенно если мы говорим про функцию.

Pzz>>Ну и передай туда структуру с именованными полями.
Б>Ага, а сначала не забудь определить типы структуры.
А это определение чем-то сложнее перечисления параметров в сигнатуре функции получится?

struct f_args {
    int i;
    double d;
    char c = 0;
};
void f(f_args args) {}

int main() {
    f({.i = 1, .d = 0.5});
    return 0;
}

Мне кажется такое можно даже макросами делать.

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

Ф>>Это тебе гарантирует
D>Ничего это не гарантирует. В любой момент можно баг словить, даже идеального( ) решарпера.

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

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

M>

M>struct f_args {
M>    int i;
M>    double d;
M>    char c = 0;
M>};
M>void f(f_args args) {}

M>int main() {
M>    f({.i = 1, .d = 0.5});
M>    return 0;
M>}
M>

M>А это определение чем-то сложнее перечисления параметров в сигнатуре функции получится?

Конечно, это сложнее. Сравни с "правильным" вариантом:

void f(int i, double d, char c = 0) {}

int main() {
    f(i = 1, d = 0.5);
    return 0;
}

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

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

Ф>>>Это тебе гарантирует
D>>Ничего это не гарантирует. В любой момент можно баг словить, даже идеального( ) решарпера.

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

Достаточно одного маленького необработанного исключения в очередном минорном обновлении инструмента чтобы долго грустить над логерами через пару билдов.

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

D>Достаточно одного маленького необработанного исключения в очередном минорном обновлении...

Или один раз отредактировать сигнатуру руками, положившись на что, что функцию пока никто не успел заюзать. Или один раз пропустить пару из сотни мест, где используется функция — просто потому, что глаз замылился, а вызовов много.

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

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

D>>Достаточно одного маленького необработанного исключения в очередном минорном обновлении...

Ф>Или... Или...

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

Безусловно есть плюсы и за позиционные. Например в функциях типа min/max нет смысла разводить многословие, но там и порядок неважен.

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

E>Да и не редко такие объекты конструируются не руками.
Обычно да, сериализация какая нибудь. Но в тестах вижу такое постоянно.

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

Б>Конечно, это сложнее. Сравни с "правильным" вариантом:
Б>

Б>void f(int i, double d, char c = 0) {}

Б>int main() {
Б>    f(i = 1, d = 0.5);
Б>    return 0;
Б>}
Б>

Завернуть в макрос, делов-то

M>А это определение чем-то сложнее перечисления параметров в сигнатуре функции получится?

Тем, что это перечисление осуществляется в другом месте (не там где функция), что затрудняет чтение. Опять же, больше лишних строчек кода.

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

S>Вот стандартная практика — как бы по порядку. Т.е. через запятую последовательно.

S>А ведь есть более умные решения: именованные аргументы функции. Если порядок аргументов изменился, то не нужно по всему коду выискивать и исправлять.

S>Какой вариант вам удобнее?

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

А вот в окамле какой-то расколбас, что запомнилось после прочтения пары книг по этому языку — там просто две библиотеки, претендующие на стандартные, но с разными стилями именования аргументов. Только на окамле я почти не писал. Поэтому какого-то диссонанса от этого не испытал.

В Scala сделано неплохо, что особо не задумываешься. Такой хороший критерий. Когда сделано по уму, то особо не напрягает глаза, не бросается (как например, необходимость постоянно писать многоэтажные std::move в замыкании C++, тогда как в Rust это записывается очень кратко и по делу).

А это вы новый C# обсуждаете? Ужас, во что его превратили. Много лет не следил за этим гибридо-монстром

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

S>Для C++ вроде и все есть, но все жутко не удобно — ведь еще нужно писать обвязку.

Дарю лайфхак: Designated initializers

http://coliru.stacked-crooked.com/a/3c18a1b78cced9ad

struct FooParams {int a; double b = 3.14; int c; int e = 42; int f; int g; int h;};

void foo(FooParams _) {/* . . . */}

int main()
{
    foo({.a = 123, .e = 456, .h = 789});
}

P.S. Кстати говоря, такой приём даёт ещё одно преимущество — определенность в порядке инициализации параметров — строго слева направо. Тогда как порядок инициализации обычных фактических параметров функций не регламентирован.

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

S>Какой вариант вам удобнее?

В основном на джаве пишу и за последние лет 5 прикипел душой к ломбоку. Для данной задачи там есть аннотация Builder, которая превращает дата-обьект в билдер, а его можно передавать как входной параметр или результат работы метода. Это снижает количество ошибок, связанных с перепутанными аргументами одного типа, и вообще делает код читаемее.
У билдера есть ещё одно преимущество — он защищает код от использования недостроенного объекта. Т.е. пока ты явно не вызовешь метод build(), объект как бы находится на стадии конструирования и его нельзя использовать в коде, т.к. есть только билдер, а не сам объект. Причём такой недостроенный билдер можно передавать по цепочке, не опасаясь что на какой-то промежутой стадии кто-то решить заюзать недострой.

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

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

Б>Конечно, это сложнее. Сравни с "правильным" вариантом:
Б>[ccode]
Б>void f(int i, double d, char c = 0) {}

Когда такое нужно пробросить через несколько вложенных вызовов, то уже не сложнее.
Либо определение повторяется у методов наследников объектов.

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

S>>Какой вариант вам удобнее?

N>Так, как сделано в Swift.

Если бы еще не требовал писать дискарды "_" если хочешь просто позиционные параметры, а так получается, что составитель в постоянной борьбе со своей ленью, ведь для него удобнее всегда использовать именованные, чем позиционные, хотя нужны реже.

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

N>>Так, как сделано в Swift.

R>Если бы еще не требовал писать дискарды "_" если хочешь просто позиционные параметры, а так получается, что составитель в постоянной борьбе со своей ленью, ведь для него удобнее всегда использовать именованные, чем позиционные, хотя нужны реже.

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

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

Pzz>>Если в функции — сорок параметров, то эту функцию надо бы порефакторить...
S>Image: convert-table-parameters.png
S>Удачи её порефакторить

Уже, вроде, устоялось, что если более 5-ти параметров, то удобнее дать интерфейс с неким объектом property-bag (Parameters, Options, Config и т.д.), который (объект) является поставщиком параметров ф-ии. Благо, вэлью-типы позволяют провернуть такой трюк относительно дешево.

Заодно это позволяет задешево декомпозировать логику подбора параметров и целевую логику их использования затем.