Что вызовется в этом случае:

module Program
{
  Run[T](_ : T) : void { Console.WriteLine("_ : T"); }
  Run[T](params _ : array[T]) : void { Console.WriteLine("params _ : array[T]"); }

  Main() : void
  {
    Run(1, 2);
  }
}

Или почему этот код компилируется, а не выдает ошибку ?

def f(a)
{
  | (x, y) => ()
  | _ => ()
}

f(1, 2);

Все дело в неявном создании кортежа.
Посему и вопрос не стоит ли эту фичу убрать и явно указывать создание кортежа ?

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

__>Все дело в неявном создании кортежа.

Ага.

__>Посему и вопрос не стоит ли эту фичу убрать и явно указывать создание кортежа ?

Откровенно говоря эта хрень мня тоже достала, но:
1. Она весьма глубоко встроена в систему типов. Придется курочить все начиная с солвера.
2. Довольно много кода использует эту фичу. Боюсь, что даже в компиляторе его будет не мало.

Но действительно вреда от фичи куда больше чем достоинств.

Что касается явного указания, то надо предложить синтаксис.
Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.

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

VD>Но действительно вреда от фичи куда больше чем достоинств.

VD>Что касается явного указания, то надо предложить синтаксис.
VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.

Согласен, нужно это хорошо продумать.

Тут много вариантов как указать.
Скажем как-то так:

def a = (1,2);

def f(x,y) {}

f(a) // Error
f(*a) // OK

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

__>Тут много вариантов как указать.
__>Скажем как-то так:
__>

__>def a = (1,2);

__>def f(x,y) {}

__>f(a) // Error
__>f(*a) // OK
__>

Это все не очевидно. А унарное "умножение" может еще и столку сбить.

Возможно более красивым ходом было бы использовать аналог раскрытия списков в квази-цитировании:
>

def a = (1,2);

def f(x,y) {}

f(a) // Error
f(..a) // OK

Но опять же надо подумать.

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

Народ! Высказываетесь по этому поводу!

Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

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

VD>Народ! Высказываетесь по этому поводу!

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

Лично мне она не мешает. Несколько раз использовал её, но если её не станет, то не расстроюсь.

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

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
плюс адын.
Но ломающие изменения предлагаю оставлять на 2.0

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

VD>Народ! Высказываетесь по этому поводу!

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.

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

VD>>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
WH>плюс адын.
WH>Но ломающие изменения предлагаю оставлять на 2.0

Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b.

Тут можно будет писать [(1,2)].Map(fun((a,b)){ ... })

РД>Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.

Проблема в том, что это преобразование создает невероятное количество вариантов при работе с LINQ-ом.

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

Соглашаюсь с удалением этой фичи(бага)
Мне кажется, что если пишем def a = (1,2); , то a уже кортеж и использовать её как массив смысла нет... Хотя если можно это оставить, то почему бы и нет. С магическим синтаксисом, например f([a])

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

VD>def a = (1,2);

VD>def f(x,y) {}

VD>f(a) // Error
VD>f(..a) // OK

А можно так?

def tuple = (1,2);
def f(x,y) {}
f tuple;//cкобки уже есть в tuple :)

//или так:
f $ tuple;

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

VD>Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.

Ну ты приколист.
Тут на самом деле как не крути, а ломающее изменение будет — что в 1.0 по сравнению с 0.9.х, что в 2.0 по сравнению с 1.0.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно.

По всей видимости поляки именно ради такого использования внедрили эту фичу.

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

VD>Но действительно вреда от фичи куда больше чем достоинств.

+1

VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо?

Вот этот сценарий — кортеж распаковываемый в аргументы функции, мне думается автоматизировать нужно.

Но обратная операция весьма спорная, так как код подобный этому выглядит весьма странно:

def f(a) ...

f(1,2)

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

WH>Но ломающие изменения предлагаю оставлять на 2.0

Если делать ломающие изменения, то гораздо лучше делать их до первого релиза.

С исходной посылкой согласен, фича вредная.

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

VD>Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.
2.0 один хрен будет не совместима с 1.0.
У нас просто нет ресурсов чтобы в 2.0 воспроизвести все баги 1.0

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

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

WH>>Но ломающие изменения предлагаю оставлять на 2.0

SAS>Если делать ломающие изменения, то гораздо лучше делать их до первого релиза.
+1
Раз эта фича не полезна, то лучше ее продумать и внести изменения до 2-й версии.
Т.к. проблему 1-й версии это решит уже сейчас, а 2-я версия будет не очень скоро.

SAS>С исходной посылкой согласен, фича вредная.

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

H>

H>def f(a) ...

H>f(1,2)
H>

Я так понимаю, это ввели отчасти из-за... "эстетических" причин. Т.к. с Си-подобным синтаксисом вызов бы выглядел так:

f((1,2))

И в глаза бросается некоторая излишняя скобочность. Мне и самому такое не нравится. Хотя проблему отчасти решают пайпы:

f <| (1, 2)

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

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

H>>

H>>def f(a) ...

H>>f(1,2)
H>>

ВВ>Я так понимаю, это ввели отчасти из-за... "эстетических" причин. Т.к. с Си-подобным синтаксисом вызов бы выглядел так:

ВВ>

ВВ>f((1,2))
ВВ>

Что-то нечасто я вдел чтобы функция принимала чисто кортеж.

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