Предлагаю приделать к компилятору выдачу ворнинга при неявной инициализации изменяемых переменных ссылочных типов — там оказывается null, что вредно например при работе со списками и опциями, получается поведение от фазы луны — может вдруг вылезти MatchFailureException или NullReferenceException, а может и нормально работать будет. Лучше когда null там оказывается осознанно.

Вот только сам я это пожалуй не осилю сделать, вернее надо долго разбираться.

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

АП>Предлагаю приделать к компилятору выдачу ворнинга при неявной инициализации изменяемых переменных ссылочных типов — там оказывается null, что вредно например при работе со списками и опциями, получается поведение от фазы луны — может вдруг вылезти MatchFailureException или NullReferenceException, а может и нормально работать будет. Лучше когда null там оказывается осознанно.

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

А что, по твоему, там должно было оказаться? И вообще, инициализация переменных по месту объявления считается хорошим тоном.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>А что, по твоему, там должно было оказаться? И вообще, инициализация переменных по месту объявления считается хорошим тоном.

Да всё правильно, по умолчанию null. Просто иногда забываю написать = [], и хотелось бы, чтобы компилятор предупреждал, что переменная объявлена и не инициализирована.

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

АП>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>А что, по твоему, там должно было оказаться? И вообще, инициализация переменных по месту объявления считается хорошим тоном.

АП>Да всё правильно, по умолчанию null. Просто иногда забываю написать = [], и хотелось бы, чтобы компилятор предупреждал, что переменная объявлена и не инициализирована.

Можно и грязно подключать простой макрос (вроде бы работает как надо)

using Nemerle.Compiler;

macro @mutable (expr)
syntax ("mutable", expr)
{
  match (expr) {
    | <[ $a = $b ]> => 
      Parsetree.PExpr.DefMutable (expr.loc, a, b);
    | _ =>
      Message.Warning (expr.loc, "default initialized mutable value");
      Parsetree.PExpr.DefMutable (expr.loc, expr, null);
  }
}

А в компилере еще проще править, в ncc/typing/Typer.n где-то 1200 строчка

        | PT.PExpr.DefMutable (x, null) => 
          DoType (PT.PExpr.DefMutable (x, <[ $(TExpr.DefaultValue (FreshTyVar ()) : typed) ]>), expected, is_toplevel_in_seq)

Собственно тот же ворнинг кинуть, но это если без разбора типа.
Если есть желание довести это до коммита, то еще надо бы номер придумать предупреждению, отключить по умолчанию, подумать над типами и текстом, выложить патч на всеобщее обсуждение

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

ИД>Можно и грязно подключать простой макрос (вроде бы работает как надо)

ИД>А в компилере еще проще править, в ncc/typing/Typer.n где-то 1200 строчка
ИД>

ИД>        | PT.PExpr.DefMutable (x, null) => 
ИД>          DoType (PT.PExpr.DefMutable (x, <[ $(TExpr.DefaultValue (FreshTyVar ()) : typed) ]>), expected, is_toplevel_in_seq)
ИД>

ИД>Собственно тот же ворнинг кинуть, но это если без разбора типа.

Но это всё не распространяется на переменные-поля, а хотелось бы. Даже больше, чем для локальных, потому что локальных изменяемых переменных у меня почти и нет

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

АП>Предлагаю приделать к компилятору выдачу ворнинга при неявной инициализации изменяемых переменных ссылочных типов — там оказывается null, что вредно например при работе со списками и опциями, получается поведение от фазы луны — может вдруг вылезти MatchFailureException или NullReferenceException, а может и нормально работать будет. Лучше когда null там оказывается осознанно.

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

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

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

АП>Да всё правильно, по умолчанию null. Просто иногда забываю написать = [], и хотелось бы, чтобы компилятор предупреждал, что переменная объявлена и не инициализирована.

Предлагаю сделать по дургому. Ввести атрибут, что-то вроде элемент варианта по умолчанию, и если он есть, то инициализировать переменные по умолчанию именно этим значением. Тогда поведение по умолчанию будет таким как интуитивно предпологает программист. Для списка элементом принятым по умолчанию будет Nil.

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

VD>Здравствуйте, Алексей П, Вы писали:

АП>>Да всё правильно, по умолчанию null. Просто иногда забываю написать = [], и хотелось бы, чтобы компилятор предупреждал, что переменная объявлена и не инициализирована.

VD>Предлагаю сделать по дургому. Ввести атрибут, что-то вроде элемент варианта по умолчанию, и если он есть, то инициализировать переменные по умолчанию именно этим значением. Тогда поведение по умолчанию будет таким как интуитивно предпологает программист. Для списка элементом принятым по умолчанию будет Nil.

Неплохо, но может привести к обратным ошибкам в существующем коде (если это будут не только списки — для них всё должно быть ок).
И как определять, надо ли ставить это нестандартное значение — просто тупо если не указано при объявлении переменной?

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

АП>Неплохо, но может привести к обратным ошибкам в существующем коде (если это будут не только списки — для них всё должно быть ок).

Не хорошо конечно, но ведь пока не релиз не смертельно. А потом проще жить будет.

АП>И как определять, надо ли ставить это нестандартное значение — просто тупо если не указано при объявлении переменной?

Ага.

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

VD>Не хорошо конечно, но ведь пока не релиз не смертельно. А потом проще жить будет.

Рассуждая так, надо бы еще убрать из Nemerle.Collections интерфейсы IEnumerable и IEnumerator (lib/oldapi.n) — мешают при открытии одновременно N.C и System.Collections.Generic.

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

АП>Рассуждая так, надо бы еще убрать из Nemerle.Collections интерфейсы IEnumerable и IEnumerator (lib/oldapi.n) — мешают при открытии одновременно N.C и System.Collections.Generic.

Надо. И они уже помечены как запрещенные. Так что к релизу уберутся.

Но с System.Collections.GenericSystem.Collections.Generic все равно конфликт будет, так как утилитарный класс для списка имеет имя List, а это конфликтует с List[T] из System.Collections.Generic.