Можно получить переменную со значением типа void, хотя бы так:

def result = for (mutable i = 0; i < 10; i++) y++;

Собственно, вопрос. А почему это вообще компилируется? Что можно делать с переменной такого типа?

ЗЫ. А где тэг подсветки для Nemerle?

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

ВВ>Можно получить переменную со значением типа void, хотя бы так:

Нет. Компилятор сей код не пропустит (много-много ошибок покажет).
Тип void имеет тривиальный код из скобок

()

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

H>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Можно получить переменную со значением типа void, хотя бы так:
H>Нет. Компилятор сей код не пропустит (много-много ошибок покажет).

У тебя какой-то неправильный компилятор. Или у меня Beta 1, все прекрасно компилируется.

H>Тип void имеет тривиальный код из скобок
H>

H>()
H>

Тем не менее вопрос остается — почему это компилируется, что можно сделать с переменной-void?

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

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

ВВ>>Можно получить переменную со значением типа void, хотя бы так:

H>Нет. Компилятор сей код не пропустит (много-много ошибок покажет).
H>Тип void имеет тривиальный код из скобок
H>

H>()
H>

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

def v = ();
WriteLine(v);

Вообще этот тип используется в конструкциях сопоставления с образцом в неиспользуемой ветке:

match(e) {
  | ... => ...
  | _ => ()
}

Также выражения такого типа нужны в макросах для обозначения кода, который ничего не делает

def no_actions => <[ () ]>;

Все это нужно для поддержки императивного кода. В языке нет "предложений" (statements) — везде исключительно "выражения" (expressions). Абстракция предложений поддерживается выражениями, возвращающими void — (), возможность появления переменных (имен) с таким типом лишь следствие использования такой абстракции.

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

H>Все это нужно для поддержки императивного кода. В языке нет "предложений" (statements) — везде исключительно "выражения" (expressions). Абстракция предложений поддерживается выражениями, возвращающими void — (), возможность появления переменных (имен) с таким типом лишь следствие использования такой абстракции.

И это опять-таки не снимает вопроса. То, что void используется как абстракция я понимаю, но зачем он нужен в явном виде в качестве значения переменной? Концепция "все есть выражения" (иначе говоря все возвращает значения) тоже в некотором роде условность, т.к. "все" значение возвращать не может. В особенности чисто императивные конструкции, которые, хоть и в виде макросов, но поддерживаются в Немерле.

Так, собственно, зачем разрешать компилировать мой пример? Это сайд-эффект или в этом есть какой смысл? Или же компилятор просто не может здесь сгенерировать ошибку по каким-то причинам?

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

ВВ>Так, собственно, зачем разрешать компилировать мой пример? Это сайд-эффект или в этом есть какой смысл? Или же компилятор просто не может здесь сгенерировать ошибку по каким-то причинам?

Это видимо побочный эффект.

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

ВВ>Так, собственно, зачем разрешать компилировать мой пример? Это сайд-эффект или в этом есть какой смысл? Или же компилятор просто не может здесь сгенерировать ошибку по каким-то причинам?
На самом деле проблема не тут, а в дизайне .NET. Его авторы должны были сделать void полноценным типом имеющим одно значение.
Тк значение только одно то на физическом уровне это значение не нужно ни хранить ни передавать и в случае боксинга всегда возвращать ссылку на один и тот же объект.
Но на логическом это многое бы упростило. Особенно это касается генериков. Ибо сйчас приходится писать два почти идентичных вырианта один для void второй для всех остальных.

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

ВВ>Собственно, вопрос. А почему это вообще компилируется? Что можно делать с переменной такого типа?

ML, вроде бы, тоже позволяет присваивать void (0-tuple). Это не проблема.

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

DR>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Собственно, вопрос. А почему это вообще компилируется? Что можно делать с переменной такого типа?
DR>ML, вроде бы, тоже позволяет присваивать void (0-tuple). Это не проблема.

Мне просто интересно, в чем смысл такого присваивания именно в Немерле. Что я могу сделать с этой переменной? Ведь Немерле все же first class .NET язык, и я не могу эту переменную никуда передать и пр. Т.е. подобный код в Немерле неизбежно ведет к ворнингу.

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

ВВ>>Так, собственно, зачем разрешать компилировать мой пример? Это сайд-эффект или в этом есть какой смысл? Или же компилятор просто не может здесь сгенерировать ошибку по каким-то причинам?
WH>На самом деле проблема не тут, а в дизайне .NET. Его авторы должны были сделать void полноценным типом имеющим одно значение.
WH>Тк значение только одно то на физическом уровне это значение не нужно ни хранить ни передавать и в случае боксинга всегда возвращать ссылку на один и тот же объект.
WH>Но на логическом это многое бы упростило. Особенно это касается генериков. Ибо сйчас приходится писать два почти идентичных вырианта один для void второй для всех остальных.

Хз, но честно мне кажется странным, когда императивные конструкции расцениваются как right side expression:

def x = return;

Неважно, макрос это или нет. Хотелось бы ошибку.

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

ВВ>Собственно, вопрос. А почему это вообще компилируется?

Потому что система типов проектировалась таким образом, чтобы все можно было рассматривать выражением (возвращать значения). Но в реальном мире бывают места где выражения не уместны. В таких местах, чтобы не нарушать концепцию, считается, что используется выражение типа void.

ВВ>Что можно делать с переменной такого типа?

Ничего. Ну, разве что присвоить в другую переменную того же типа.

ВВ>ЗЫ. А где тэг подсветки для Nemerle?

В форматере она поддерживается, но по всей видимости на сайт новая версия форматера еще не попала.

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

ВВ>>Собственно, вопрос. А почему это вообще компилируется?
VD>Потому что система типов проектировалась таким образом, чтобы все можно было рассматривать выражением (возвращать значения). Но в реальном мире бывают места где выражения не уместны. В таких местах, чтобы не нарушать концепцию, считается, что используется выражение типа void.

Т.е. это чисто идеологическое решение? А чем было бы плохо в таких случаях все же генерировать ошибку? Например, мы считаем, что некоторые expressions нельзя использовать в правой части выражения. Это относится не только к макросам, но и даже к оператору "=". Все же язык гибридный.

ВВ>>Что можно делать с переменной такого типа?
VD>Ничего. Ну, разве что присвоить в другую переменную того же типа.

Ну т.е. по факту, если я напишу:

def x = ();

от ворнинга никак не избавиться?

ВВ>>ЗЫ. А где тэг подсветки для Nemerle?
VD>В форматере она поддерживается, но по всей видимости на сайт новая версия форматера еще не попала.

Ждем

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

ВВ>И это опять-таки не снимает вопроса. То, что void используется как абстракция я понимаю, но зачем он нужен в явном виде в качестве значения переменной?

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

ВВ>Концепция "все есть выражения" (иначе говоря все возвращает значения) тоже в некотором роде условность, т.к. "все" значение возвращать не может. В особенности чисто императивные конструкции, которые, хоть и в виде макросов, но поддерживаются в Немерле.

Макросы не могут сдалать не императивный язык императивным. Они лишь дают привычный синтаксис. А вот ту самую императивность дает возможность присвоения новых значений переменным и возможность задавать выражениям тип void.

ВВ>Так, собственно, зачем разрешать компилировать мой пример? Это сайд-эффект или в этом есть какой смысл? Или же компилятор просто не может здесь сгенерировать ошибку по каким-то причинам?

Разрешается все что проходит контроль типов.

Лучше скажи что тебя не устраивает в том, что можно создать выражение типа void и присвоить его результат переменной того же типа?

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

ВВ>Хз, но честно мне кажется странным, когда императивные конструкции расцениваются как right side expression:

ВВ>def x = return;

ВВ>Неважно, макрос это или нет. Хотелось бы ошибку.

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

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

ВВ>Т.е. это чисто идеологическое решение?

Оно так складывается если просто действовать по правилам.

ВВ>А чем было бы плохо в таких случаях все же генерировать ошибку?

А зачем? Ты первый недовольный. Если таких появится несколько будем думать. Пока что на практике это проблем не вызывало.


ВВ> Например, мы считаем, что некоторые expressions нельзя использовать в правой части выражения. Это относится не только к макросам, но и даже к оператору "=". Все же язык гибридный.

А что это даст? От чего убережет?

ВВ>Ну т.е. по факту, если я напишу:
ВВ>def x = ();
ВВ>от ворнинга никак не избавиться?

Есть сразу три пути избавления от ворнинга:
1. Написать:

def x = ();
_ = x;

2. Написать:

def x = ();
x;

3. Не писать глупого кода.

VD>>В форматере она поддерживается, но по всей видимости на сайт новая версия форматера еще не попала.

ВВ>Ждем

Я сайтом не занимаюсь. В Янусе он наверно уже даже работает. Точно работает в новом шаблоне подготовки статей для РСДН.

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

VD>Лучше скажи что тебя не устраивает в том, что можно создать выражение типа void и присвоить его результат переменной того же типа?

Вообще изначальный вопрос был: А не делаете ли с void что-то такое, о чем я не знаю?

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

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

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

Он имеет смысл с концептуальной точки зрения. Лучше допускать бессмысленный код чем объяснять почему логически корректный код не может быть написан.

Потом есть одно эмпирическое правило — чем больше запретов, тем выше вероятность, что они помешают в жизни. По этому нужно найти серьезные предпосылки, чтобы что-то запрещать. Есть стройная система типов основанная на определенном алгоритме. Приведенные тобой примеры — это их следствие. Да, не обычно для тех кто писал на C#. Но вполне логично.

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

VD>Потом есть одно эмпирическое правило — чем больше запретов, тем выше вероятность, что они помешают в жизни. По этому нужно найти серьезные предпосылки, чтобы что-то запрещать. Есть стройная система типов основанная на определенном алгоритме. Приведенные тобой примеры — это их следствие. Да, не обычно для тех кто писал на C#. Но вполне логично.

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