Никто не знает, они не собираются в будущем добавить такую вещь:
void Foo(int a, params int[] b, int c)
{
}
void Bar(params string[] s, int a)
{
}
Т.е. чтобы неопределенное количество параметров можно было сделать в середине или в начале сигнатуры. Мне как-то раз такого не хватало, приходилось делать порядок аргуметов не совсем таким каким хотелось.
S>http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/116
интересно, добавят ли когда-нибудь хотя бы урезанный pattern matching. и тогда исключения можно было бы матчить. и странно что index initializers только сейчас добавили. не то чтобы мне это нужно было, но просто пару раз я пытался так делать, — мне казалось должно по логике вещей такое работать, а оно не работало
Здравствуйте, Анон, Вы писали:
А>Т.е. чтобы неопределенное количество параметров можно было сделать в середине или в начале сигнатуры. Мне как-то раз такого не хватало, приходилось делать порядок аргуметов не совсем таким каким хотелось.
Нет, это здорово усложнит вывод перегрузок.
Просто фильтры на исключения добавили. PM с исключениями не будет с вероятностью .999. Самый простой аргумент: обработка исключений в пару тысяч раз медленнее вызова простого метода (в десятки тысяч — для длинных стеков). И без ломающих изменений это к сожалению не поправить.
Чуть посложнее: логика на исключкениях противоречит FDG.
BS>и странно что index initializers только сейчас добавили. не то чтобы мне это нужно было, но просто пару раз я пытался так делать, — мне казалось должно по логике вещей такое работать, а оно не работало
Как всегда: никто не задокументировал, не закодил, не проверил, не выпустил в продакшн. Вот "Extension Add in collection initializers" куда интереснее, но тож не особо нужен.
Здравствуйте, AndrewVK, Вы писали:
А>>Т.е. чтобы неопределенное количество параметров можно было сделать в середине или в начале сигнатуры. AVK>Это, очевидно, сделать в общем случае невозможно.
Подразумевалось, что только один параметр в сигнатуре может иметь модификатор params.
Здравствуйте, Анон, Вы писали:
AVK>>Это, очевидно, сделать в общем случае невозможно. А>Подразумевалось, что только один параметр в сигнатуре может иметь модификатор params.
Даже один модификатор params, если он не на последнем месте, легко приводит к неоднозначностям.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Даже один модификатор params, если он не на последнем месте, легко приводит к неоднозначностям.
А можно пример?
Неоднозначности при выборе нужного перегруженного метода возможны. Но их, как мне кажется, будет не больше, чем в ситуации, если params на последнем месте.
AVK>Да. А почему урезанный?
ну я в том смысле. что хоть какой. просто если до сих пор нет, значит есть некоторые сложности. AVK>С исключениями не все так просто.
а почему?
Здравствуйте, BrainSlug, Вы писали:
AVK>>Да. А почему урезанный? BS>ну я в том смысле. что хоть какой. просто если до сих пор нет, значит есть некоторые сложности.
Сложности все уже решены, PM и что то на тему maybe монады будут основным фокусом следующего релиза.
AVK>>С исключениями не все так просто. BS>а почему?
Потому что exception filter это фича CLR.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, AndrewVK, Вы писали:
AVK>>что то на тему maybe монады будут основным фокусом следующего релиза.
J>В C# 6.0 же оператор ?. будет, что еще надо то?? J>А про not-null-reference types что нить слышно??
nameof мб врубят. Для меня самое полезное — await в catch\finally, особенно в finally ибо не обойти нормально было.
P.S. PM в том виде что выложили имхо ещё то извращение. https://roslyn.codeplex.com/discussions/552375 тут в последнем сообщении накатал что думаю об этом в частности. Вкратце — вместо ПМа было бы очень найс видеть возможность управления областями видимости.
А в целом и так всё неплохо, в крайнем случае есть немерл
Здравствуйте, Jack128, Вы писали:
AVK>>что то на тему maybe монады будут основным фокусом следующего релиза. J>В C# 6.0 же оператор ?. будет, что еще надо то??
Какая связь?
J>А про not-null-reference types что нить слышно??
А maybe, по твоему, для чего?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Jack128, Вы писали:
AVK>>>что то на тему maybe монады будут основным фокусом следующего релиза. J>>В C# 6.0 же оператор ?. будет, что еще надо то??
AVK>Какая связь?
ну как, по моему ?. это и есть спец. сахар для ссылчоных/нуллабл типов, которые по сути и есть maybe (не строго монада, но для шарпа сойдет)
в C#5 уже есть обобщенный сахар для монад и мы могли бы написать так: (реализовав соответствующие экстеншен методы)
{
var o = new object();
var ty =
from x in o
from t in x.GetType()
select x;
Assert.IsNotNull(ty);
o = null;
ty =
from x in o
from t in x.GetType()
select x;
Assert.IsNull(ty);
}
но это ж некузяво, потому в C#6 мы можем писать так: ty = o?.GetType();
J>>А про not-null-reference types что нить слышно??
AVK>А maybe, по твоему, для чего?
хз. Maybe могут принимать либо спец. значение None(null) либо реальное значение. А хочется иметь тип, который бы запрещал передачу этого специального null'а
Здравствуйте, Jack128, Вы писали:
J>ну как, по моему ?. это и есть спец. сахар для ссылчоных/нуллабл типов, которые по сути и есть maybe (не строго монада, но для шарпа сойдет)
Элвис-оператор, разумеется, это сахар для nullable типов, то это никоим образом не maybe. Maybe, в отличие от этого оператора, принуждает правильно обрабатывать null.
AVK>>А maybe, по твоему, для чего? J>хз.
Это вот как раз один из вариантов реализации not-nullable types.
J>А хочется иметь тип, который бы запрещал передачу этого специального null'а
Это тоже в основных планах. А так же аналогичная механика для immutable типов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Если нам не помогут, то мы тоже никого не пощадим.
