S> То есть ты против C# Source Generators как факт. Ты за макросы в C# которых скоро точно не будет? Лучше журавль, но в небе. S>Если бы да бы …
Я не против source generators, я последовательный противник подхода "лепить мелкие фичи по одной в год". Сейчас в роадмапе C#9 идёт обсуждение разных видов record types, и каждое обсуждение застревает в десятках деталей: "а как будут объявляться init-only поля", "а как мы будем говорить что какое-то поле исключить из GetHashCode / Equals", и т.д.
S> Можно говорить, что феррари лучше чем жигули, только от того, что говоришь жигули не станут Феррари. S>В итоге нужно ходить пешком?
Что делает водитель когда рулит ведром с гайками, и при этом точно знает что тот же завод, за те же деньги, мог выпустить Феррари? Едет и матерится
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, varenikAA, Вы писали:
AA>>Но C#(не удержусь), движется по скользому пути — добавляет в компилятор кучу фичей имеющих неоднозначный смысл: например, два вида switch — один конструкция(старое), другой выражениие(новое), причем ограниченное функциями возврата, т.е. только return из функции, но не var x = switch.
_NN>Кто это вам сказал ? _NN>https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/switch-expression
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, varenikAA, Вы писали:
AA>>>Но C#(не удержусь), движется по скользому пути — добавляет в компилятор кучу фичей имеющих неоднозначный смысл: например, два вида switch — один конструкция(старое), другой выражениие(новое), причем ограниченное функциями возврата, т.е. только return из функции, но не var x = switch.
_NN>>Кто это вам сказал ? _NN>>https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/switch-expression
AA>_ _NN>> Directions.Left => Orientation.West,
AA>А если return вместо => ?
Нет проблем
public static class SwitchExample
{
public enum Directions
{
Up,
Down,
Right,
Left
}
public enum Orientation
{
North,
South,
East,
West
}
public static Orientation a()
{
var direction = Directions.Right;
return direction switch
{
Directions.Up => Orientation.North,
Directions.Right => Orientation.East,
Directions.Down => Orientation.South,
Directions.Left => Orientation.West,
};
}
}
Здравствуйте, Serginio1, Вы писали:
S>initonly это для обязательной инициализации. readonly только в полю, а initonly к свойству
На минутку, св-ва это сахар к методам как они могут быть инитонли?
вся эта инитонли сводится к объявлению конструктора с инициализацией readonly. Что творится на свете!
Выражение switch предоставляет в контексте выражения семантику, аналогичную switch. Оно предоставляет краткий синтаксис, когда ветви switch возвращают значение. В следующем примере показана структура выражения switch.
В документации утверждается, что оба выражения switch идентичны, но это не так.
//инструкцияswitch(direction)
{
case Directions.Down:
return Orientation.East;
default:
return Orientation.North;
};
//выражение var x = direction switch
{
Directions.Up => Orientation.North,
Directions.Right => Orientation.East
};
Отличий море как синтаксических, так и семантических.
Уж лучше бы match .. with ввели. Башню сносит от такой каши.
Здравствуйте, varenikAA, Вы писали:
AA>Я о другом AA>
AA>Выражение switch предоставляет в контексте выражения семантику, аналогичную switch. Оно предоставляет краткий синтаксис, когда ветви switch возвращают значение. В следующем примере показана структура выражения switch.
AA>В документации утверждается, что оба выражения switch идентичны, но это не так.
The switch expression provides for switch-like semantics in an expression context. It provides a concise syntax when the switch arms produce a value.
Тут не утверждается, что семантика и синтаксис идентичные, "-like" т.е. похожие.
Конечно лучше было иметь "всё есть выражение" и сразу предоставить сопоставление с образцом, но в 2000-ом это было не модно, да и люди из Java не смогли бы легко переходить.
Здравствуйте, Михаил Романов, Вы писали:
МР>Думаю, что ничего МР>
Run un-ordered, each generator will see the same input compilation, with no access to files created by other source generators.
Ну то есть их включили в отдельную фазу компиляции, и одним махом зарубили как потенциальные проблемы из-за различий семантики при разном порядке прогона генераторов, так и потенциальные бенефиты от многопроходной генерации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну то есть их включили в отдельную фазу компиляции, и одним махом зарубили как потенциальные проблемы из-за различий семантики при разном порядке прогона генераторов, так и потенциальные бенефиты от многопроходной генерации.
Похоже на то.
При этом (если я понял всё правильно — увы, руки пока не дошли попробовать), результаты анализа того, что порождает Source Generator будут добавляться в общую синтаксическую и семантическую модель.
Ну т.е. на сгенерированные классы можно будет сослаться из остального кода в Design-Time (как, например, с кодом порождаемым в WPF из XAML), а это, имхо, уже немало.
Здравствуйте, hi_octane, Вы писали:
S>> То есть ты против C# Source Generators как факт. Ты за макросы в C# которых скоро точно не будет? Лучше журавль, но в небе. S>>Если бы да бы … _>Я не против source generators, я последовательный противник подхода "лепить мелкие фичи по одной в год". Сейчас в роадмапе C#9 идёт обсуждение разных видов record types, и каждое обсуждение застревает в десятках деталей: "а как будут объявляться init-only поля", "а как мы будем говорить что какое-то поле исключить из GetHashCode / Equals", и т.д.
Ну всетаки развивается. Мне например больше интересны шейпы https://www.c-sharpcorner.com/article/candidate-features-for-c-sharp-9/
А их уже и не обсуждают. S>> Можно говорить, что феррари лучше чем жигули, только от того, что говоришь жигули не станут Феррари. S>>В итоге нужно ходить пешком? _>Что делает водитель когда рулит ведром с гайками, и при этом точно знает что тот же завод, за те же деньги, мог выпустить Феррари? Едет и матерится
Но все же едет
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>>initonly это для обязательной инициализации. readonly только в полю, а initonly к свойству
AA>На минутку, св-ва это сахар к методам как они могут быть инитонли? AA>вся эта инитонли сводится к объявлению конструктора с инициализацией readonly. Что творится на свете!
Здравствуйте, Михаил Романов, Вы писали:
МР>При этом (как минимум в теории, но надеюсь и на практике всё получится) — у вас всё сразу должно подхватываться в IDE.
Я поковырял пример. 2019-я студия не видит типы и нэймспейсы "из будущего". Может, потом допилят.
Здравствуйте, Mihas, Вы писали:
M>Я поковырял пример. 2019-я студия не видит типы и нэймспейсы "из будущего". Может, потом допилят.
В исходной статье говорят про VS Preview https://visualstudio.microsoft.com/vs/preview/ — возможно, поддержка есть там.
Ну и еще нашел в статье:
Why do I not get IntelliSense for generated code? Why does Visual Studio say there’s an error even though it builds?
You will need to restart Visual Studio after building the source generator to make errors go away and IntelliSense appear for generated source code. After you do that, things will work. Currently, Visual Studio integration is very early on. This current behavior will change in the future so that you don’t need to restart Visual Studio
Не знаю только, это относится тоже к VS Preview или подхватится в 2019...
Думаю шейпы отменились, потому что их надо начинать с нуля из-за C++. У C++ вышел очень интересный взгляд на контракты: concepts/requires. После него любые другие способы выглядят убогими и ограниченными. Если бы это появилось у какого-то языка типа Scala/Nemerle и т.д. — создателям C# можно было бы эту находку "не заметить". Но на C++ в самой MS очень много пишут, так что придётся выдумывать что-то подобное для C#.
Здравствуйте, hi_octane, Вы писали:
S>>Еще раз readonly относится к полю. Видно, что бы не ломать решили добавить initonly. При этом ты возмущался двумя switch. S>>Ну не проблема это мелочи какието. Вот шейпов не добавили в С#9 вот это огорчение. https://www.c-sharpcorner.com/article/candidate-features-for-c-sharp-9/
_>Думаю шейпы отменились, потому что их надо начинать с нуля из-за C++. У C++ вышел очень интересный взгляд на контракты: concepts/requires. После него любые другие способы выглядят убогими и ограниченными. Если бы это появилось у какого-то языка типа Scala/Nemerle и т.д. — создателям C# можно было бы эту находку "не заметить". Но на C++ в самой MS очень много пишут, так что придётся выдумывать что-то подобное для C#.
Зачем с нуля? Что кодогенерацию отменили? Мы как раз в этой теме и сидим. Мы вместо явного интерфейса используем op методы, которые мы можем и явно подменить.
Смысла особого нет для тех же числовых типов использовать op_XXX
public shape SGroup<T>
{
static T operator +(T t1, T t2);
static T Zero {get;}
}
Если нужно переопределить для типа
public extension IntGroup of int: SGroup<int>
{
public static int Zero => 0;
}
Например сравнивая с дженериками то для value типов генерится отдельный класс. Это ничем не отличается от шейпов
public static AddAll<T>(T[] ts) where T: SGroup<T> // shape used as constraint
{
var result = T.Zero; // Making use of the shape's Zero property foreach (var t in ts) { result += t; } // Making use of the shape's + operator return result;
}
и солнце б утром не вставало, когда бы не было меня
S>Зачем с нуля? Что кодогенерацию отменили? Мы как раз в этой теме и сидим. Мы вместо явного интерфейса используем op методы, которые мы можем и явно подменить. S>Смысла особого нет для тех же числовых типов использовать op_XXX
С арифметикой можно было бы вырулить сравнительно малой кровью. Но есть задачки посложнее. Причиной появления шейпов было то что в существующих дженериках хрен запишешь ограничение "тип T имеет статический метод Create(int, string)" или "имеет экземплярный или экстеншен метод GetAwaiter()", при том что в обсуждении развития языка всё больший упор делается на развитие возможностей extension методов (например поддержку GetEnumerator() расширений), и т.д. C++ показал как это сделать относительно красиво и читабельно. Имея возможность такой записи, нужно думать — может можно шейпы вообще не вводить, и все сценарии закрываются дженериками, а значит не требуют и серьёзных изменений рантайма.
AA>Это правда будет в C#? и можно будет типы определять после имени? УРА!!!
Просто скопировали из Nemerle-кода, и не поправили форматирование На рослине писать прототипы новых фич сложно и долго.
Здравствуйте, hi_octane, Вы писали:
S>>Зачем с нуля? Что кодогенерацию отменили? Мы как раз в этой теме и сидим. Мы вместо явного интерфейса используем op методы, которые мы можем и явно подменить. S>>Смысла особого нет для тех же числовых типов использовать op_XXX _>С арифметикой можно было бы вырулить сравнительно малой кровью. Но есть задачки посложнее. Причиной появления шейпов было то что в существующих дженериках хрен запишешь ограничение "тип T имеет статический метод Create(int, string)" или "имеет экземплярный или экстеншен метод GetAwaiter()", при том что в обсуждении развития языка всё больший упор делается на развитие возможностей extension методов (например поддержку GetEnumerator() расширений), и т.д. C++ показал как это сделать относительно красиво и читабельно. Имея возможность такой записи, нужно думать — может можно шейпы вообще не вводить, и все сценарии закрываются дженериками, а значит не требуют и серьёзных изменений рантайма.
Шаблоны С++ это беда С++ особенно когда компиляция идет часами. Шейпы это не шаблоны, это контракт на операторы и их реализацию, этакая разновидность интерфейсов. В дженериках такого нет.
Но есть вполне можно написать
public shape SGroup<T>
{
static T operator +(T t1, T t2);
static T Zero {get;}
static T Create(int i, string s);
}
Если он есть , то используем если нет или нужно переопределить то
public extension IntGroup of int: SGroup<int>
{
static T Create(int i, string s)
{
….
}
}
и солнце б утром не вставало, когда бы не было меня
