Небольшое вступление.
Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
Проголосовать за конкретные фичи можно здесь
Здравствуйте, AndrewVK, Вы писали:
AVK>При чем тут компилятор шарпа? Это вопрос к CLR.
Ну, это как сказать. С одной стороны да. С другой стороны, CLR — это в первую очередь C#, так же как JVM это в первую очередь Java. Они неразрывно связанны и обсуждение одного в отрыве от второго бессмысленно.
Здравствуйте, kaa.python, Вы писали:
KP>Ну, это как сказать.
Как ни говори — в контексте данного вопроса это точно обсуждать смысла нет.
KP>С другой стороны, CLR — это в первую очередь C#
Я бы так не сказал. В любом случае — изменения в CLR это уже точно революция, и это другая команда. И вообще это больше политика, нежели технический вопрос.
... << RSDN@Home 1.2.0 alpha 5 rev. 23 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
Если брать мелочи, мне было бы интересно видеть более удобную работу со строками а-ля питон.
Вот например, (псевдо)код на питоне (копипаста из документации)
word = 'HelpA'
>>> word[2:4]
'lp'
>>> word[:2]
'He'
>>> word[2:]
'lpA'
>>> word[-1] # The last character
'A'
>>> word[-2] # The last-but-one character
'p'
>>> word[-2:] # The last two characters
'pA'
>>> word[:-2] # All but the last two characters
'Hel'
Здравствуйте, AndrewVK, Вы писали:
AVK>Небольшое вступление. AVK>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь. AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться. AVK>Проголосовать за конкретные фичи можно здесь
Вряд ли скажу big thing, но мелкие доработки были бы очень даже неплохи. Сам начинал с C#, потом судьба забросила на Java, и могу сказать, что оба языка прекрасны, и всё же C#-у стоило бы позаимствовать некоторые Java-фишки.
Строгий типизированный "объектный" enum, как в Java 1.5. Здорово решают проблему хранение некоего "регистра" того или иного набора данных. В отличии от примитивных целочисленных констант в шарпе, в Java можно не хило так "полиморфировать" enum-константы, наделяя их реализациями интерфейсов, абстрактных методов, не говоря уже об обычных полях и методах. Небезысвестный Jon Skeet уже как семь лет назад говорил о таком. Компилятор справился бы с перечислениями, я думаю, без изменения CLR.
Возможно, пересмотреть всеобъемлющую директиву using, которая открывает иногда слишком много. В этом контексте я бы пересмотрел также импорт методов расширения, которые не пойми откуда появляются, а также добавил бы "статический импорт": после Java, с её возможностью импортирования статических методов и полей, Console.WriteLine() выглядит уродливо. И если с первыми двумя уже, скорее всего, уже ничего не поделать, то третье можно привинтить было бы.
Возможно, виртуальные методы расширения, как в Java 8 (единственное поведение по умолчанию для интерфейсов как бы "встраивается" без необходимости открывать методы расширения, реализация поведения которых зависит, в принципе, от того, что открыто). Но, наверно, это сомнительное пожелание в контексте уже существующих методов-расширений C#.
После анонимных классов в Java руки автоматически тянутся писать такое же и в C#-коде. Можно, конечно, часто обойтись делегатами, но анонимные классы в Java позволяют инкапсулировать состояние.
Сигнатурные ограничения для конструкторов обобщённых типов: не просто конструктор по умолчанию, а возможность указать желаемую сигнатуру конструктора объекта. Например, для инджектирования объекта через конструктор, а не через свойства -- раз и до конца жизни объекта.
Лично мне "as" не очень нравится. Может быть, такое:
cast ( oldVar as Type newVar ) { ... }
вместо
var newVar = oldVar as Type;
if ( newVar != null ) {
...
}
Часто работаю с рефлексией на Java, но и там самая крутая возможность ссылаться на что-то без строки с именем, а по имени напрямую -- Type.class (typeof(Type) в C#). Иногда очень хочется такого и для методов (делегаты делают нечто похожее), полей и свойств. Таким образом рефакторинг таких вещей происходил бы менее болезненно.
И всякие плюшки в виде интерполированных строк, литералы для регулярок, этц, хотя это уже на любителя...
А если big thing, то, наверное, макросы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Небольшое вступление. AVK>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь. AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
Последнее, что я слышал — все по уши застряли в Рослине, сильно сомневаюсь, что у них хватит сил на что-то ещё. Из мелочей в голову приходит только вот это:
1. По аналогии с [CallerMemberName] и прочими — [ArgExpression]: текст выражения в заданном атрибуте:
public static void AssertFileExists(string filePath, [ArgExpression("filePath")] argName = "")
{
if (!File.Exists(filePath))
throw new ArgumentException(argName, "...");
}
// ...
AssertFileExists(someClass.SomePath); // throws ArgumentException, argument name = "someClass.SomePath"
2. Явный duck typing, что то вида
class A { SomeMethod(); } // Чужая сборка.interface IB { SomeMethod(); }
// ...var a = new A()
var b = a mapas IB; // синтаксис - первый пришедший в голову. Всё разруливается в compile time - генерится обёртка, строчка превращается в b = new <>c__Wrapper_A_IB(a).
Для скриптов (раз уж у нас шарп в ближайшем будущем можно будет хостить) можно дополнить анонимные типы до того, что есть в яве и добавить возможность передавать анонимные типы шарпа за границы метода (пускай и только для internal/protected-методов).
Ещё, судя по полунамёкам Липперта (сейчас не найду, но было ещё в паре статей), compiler team периодически думает над добавлением явного маппинга "ключевое слово — вызов подходящего метода", как это сделано для linq/foreach/await. Выглядит интересно, но насколько оно будет полезно на практике —
Здравствуйте, AndrewVK, Вы писали:
AVK>Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь. AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда :) AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
— Вывод типов при вызове констркуторов.
— nameof/infoof и т.п.
— приделать к query comprehensions to list, to array, first, single, top, skip и т.п.
— ПМ и АТД.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Цыба, Вы писали:
Ц>Небезысвестный Jon Skeet уже как семь лет назад говорил о таком. Компилятор справился бы с перечислениями, я думаю, без изменения CLR.
При всем моем уважении к Скиту, его идея супернавороченных enum'ов мне не нравится. Что чаще всего надо? Парсинг и прочие конвертеры привязать к enum'у, чтобы не болтались в левых классах типа Utils. То есть, если иметь возможность добавить статические методы, этого более чем достаточно. Объявлять enum каким-то class enum совсем не надо. Ну, или, если хочется иметь методы .To(), можно сделать как в мутаторах — в контексте нестатических методов enum'а считать value ключевым словом.
Все остальное решается через наследование. Наследуйся, там добавишь все, что надо. Примерно, как от класса с одним целочисленным полем. Соответственно, доступ к значению через то же самое base.value.
Если нам не помогут, то мы тоже никого не пощадим.
