Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Jack128, Вы писали:
J>>Это вообще нормально ?? S>Это наименьшая из проблем с туплами.
Ну как сказать, если компилятор не отслеживает имена туплов, но нафиг они вообще сдались? Я с таким же успехом могу dynamic[] использовать
Здравствуйте, Jack128, Вы писали:
S>>Это наименьшая из проблем с туплами. J>Ну как сказать, если компилятор не отслеживает имена туплов, но нафиг они вообще сдались? Я с таким же успехом могу dynamic[] использовать
Ну, если производительность не волнует, то можно и dynamic.
А так — забить и ждать records. Если и их не поломают, то тюплы пропадут за ненадобностью.
Здравствуйте, Sinix, Вы писали:
S>А так — забить и ждать records. Если и их не поломают, то тюплы пропадут за ненадобностью.
Да, дизайн от Майкрософт выдержан в лучших традициях. 10 дизайна, рассказов про обход граблей... и вот чудо уже близко, но, нет — грабли идут в комплекте.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexzzzz, Вы писали:
J>>Это вообще нормально ??
A>Имхо, это даже удобно.
Они уже 10 лет никак кортежи сделать не могут. Долгое время обосновывали это тем, что в кортежах поля не именованные и это будет приводить к багам вида:
Foo() : int * int
{
(GetX(), GetY())
}
def (y, x) = Foo();
И вот после 10 лет дизайна нам объявляют, что проблема решена, но оказывается, что исходная проблема присутствует вершении.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И вот после 10 лет дизайна нам объявляют, что проблема решена, но оказывается, что исходная проблема присутствует вершении.
Ну а варианты-то какие? struct equality CLR у нас не поддерживает, получаем или текущий вариант, или поведение вида "поменял имя, не перекомпилировал зависимые сборки, всё работает, хотя не должно", или отдельные типы для каждого возвращаемого результата.
Для второго есть предупреждения в виде рослиновских анализаторов —
IDE0032 и CS8123 (issue + то, что есть по факту).
Для третьего (и самого правильного, как по мне) — ждём рекорды.
Вообще, нынешний релиз — рекордсмен по спорным решениям. Тюплы, private methods, видимость out var-переменных, куча "внезапно легального" кода из-за ref return — я такого количества WTF moments с первого шарпа не припомню.
Здравствуйте, Sinix, Вы писали:
VD>>И вот после 10 лет дизайна нам объявляют, что проблема решена, но оказывается, что исходная проблема присутствует вершении. S>Ну а варианты-то какие?
Здравствуйте, seregaa, Вы писали:
S>Если серьезно, то про "не хочу думать" никто не говорил.
Опс, не так понял, значит. Сорри.
Исходный вопрос был про "Не вопрос, какое поведение должно быть?", вариант "делать, а не сопли жевать" к нему не очень подходит
Здравствуйте, Sinix, Вы писали:
S>>Если серьезно, то про "не хочу думать" никто не говорил. S>Опс, не так понял, значит. Сорри. S>Исходный вопрос был про "Не вопрос, какое поведение должно быть?", вариант "делать, а не сопли жевать" к нему не очень подходит
Ок. Я написал "делать быстрее" и имел ввиду весь цикл — проектирование, обсуждение, реализация и пр.
Здравствуйте, Sinix, Вы писали:
S>Да их и так ускорили до неприличного. Результат — баги в компиляторе в RC. Свежачок.
Ты правильно написал — ускорили "до неприличного". Существуют же промежуточные варианты.
К тому же фича, про которую говорится в дефекте, не совершенно новая — Эрик еще в 2010 году экспериментальную версию c# собирал с поддержкой ref returns.
Выглядит так, что вместо ускорения всего цикла, ускорили только реализацию/тестирование.
Здравствуйте, VladD2, Вы писали:
J>>>Это вообще нормально ?? A>>Имхо, это даже удобно. VD>И вот после 10 лет дизайна нам объявляют, что проблема решена, но оказывается, что исходная проблема присутствует вершении.
Я примерно понимаю, про что ты, но не понимаю, почему это проблема, почему имена важны.
int x = 1;
int y = 2;
DoStuff(y, x);
int x, y;
(y, x) = GetStuff();
(int y, int x) = GetStuff();
(int y, int x) result = GetStuff();
void DoStuff(int x, int y)
{
...
}
(int x, int y) GetStuff()
{
return ...
}
Вполне себе симметрично, однообразно, предсказуемо и быстро. Есть конечно именованные агрументы, но я не видел, чтобы их часто использовали. А когда используют, то скорее для самокомментирования DoStuff(height: 10, width: 20, timeout: 1000), чем в попытке избежать путаницы в порядке аргументов или чтобы специально менять их порядок.
Глядя на пример из первого поста, я бы подумал, что автор специально переименовал элементы тупла так, как ему надо. Иначе влепил бы просто var items.
Здравствуйте, alexzzzz, Вы писали:
A>Я примерно понимаю, про что ты, но не понимаю, почему это проблема, почему имена важны.
Вот им и говорили, что имена не так важны. Говорили, мол "Сделайте не именованные кортежи". А они отвечали, что "это плохо! Будут ошибки! Надо делать именованные поля! Чтобы их проверял компилятор...". Ну, и через 10 лет после этого мы видим, что видим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот им и говорили, что имена не так важны. Говорили, мол "Сделайте не именованные кортежи". А они отвечали, что "это плохо! Будут ошибки! Надо делать именованные поля! Чтобы их проверял компилятор...". Ну, и через 10 лет после этого мы видим, что видим.
Видим неплохой компромисс. Имена есть, не надо гадать, какой int в (int, int, int) GetData() что означает. В то же время имена ни к чему не обязывают, иначе получилось бы как с делегатами, где Func<int, bool> и Predicate<int> ― одно и то же, но друг другу хрен присвоишь.
