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

WH>В этом разница между значениями и ссылками.
Это и так понятно.
WH>И это ни коем образом не относится к возможности присвоить ссылке null.
Я так и не понял тебя.
Зачем нужен Maybe при наличии ссылочный семантики?
Вот зачем нужен Nullable<T> where T struct мне понятно и понятно зачем там констрейнт.
Но зачем он может понадобиться для ссылочных типов не могу придумать.
Или ты имеешь в виду, что есть 2 варианта ссылок: nullable & nonnullable?

Здравствуйте, VladD2, Вы писали:
VD>Дык, а зачем вообще исключения когда можно остановить проблему в зародыше (при компиляции)?
Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии. Да и внутри твоей программы могут понадобиться опциональные значения. Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!
Там, где я явно написал int?, я подразумеваю возможность отсутствия значения. И именно приведения int? к int будут выкидывать исключения.
VD>Не. Ты не понял. На стадии компиляции будет пресикаться любая попытка пораболтать с неинициализированными ссылками. А инициализировать налом будет прсото нельзя.
Я всё прекрасно понял.

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

D>В Хаскелле сделал
...
D>изволь потом матчить Maybe на предмет удачности приведения

Что мне помешает написать

toChar :: a -> Char
toChar = fromJust . cast

?

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

L>Что мне помешает написать

L>

L>toChar :: a -> Char
L>toChar = fromJust . cast
L>

L>?

L>

Это — сознательное переведение ситуации на язык throw errors:

fromJust          :: Maybe a -> a
fromJust Nothing  = error "Maybe.fromJust: Nothing" -- yuck
fromJust (Just x) = x

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

S>Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии.

Это почему же это? Если что всегда можно сделать обертку которая проверит параметры "внешнего" метода на нал и переведет нас в координаты правильной системы типов. Ну, что-то вроде интеропа в дотнете.

S> Да и внутри твоей программы могут понадобиться опциональные значения.

Читай внимательнее. Для этого есть option[T].

S> Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!

Заметил. Мой вывод был однозначинй — уроды!
А спрос на дерьмо есть только если нет предолжения не основанного на нем.

S>Я всё прекрасно понял.

А я вот увер, что нет. Ну, или не подумал как следует. Попробуй перечитать все сказанное еще рез. Уверен, что ты поймешь о чем я говорю.

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

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

VD>>Это тебе показалось или внушили. На самом деле это некий подход к декомпозиции данных. Конечно АлТД на него ложатся идеально, но и без них он полезен.
EC>
EC>Можешь дать своё определение?
EC>Здесь это определяют как:
EC>

EC>Pattern matching is used to test whether things have a desired structure, to find relevant structure, to retrieve the aligning parts, and to substitute the matching part with something else.

EC>Проверка на null это сравнение двух значений, но никак не test whether things have a desired structure.

Сори... Глядим в книгу — видеим фигу? Где в приведенной цитате хоть слово про АлТД? Мое утверждение только об этом.

EC>>>Хотя дело даже не в этом. NPE возможен когда у нас есть reference семантика.

VD>>Вот в МЛ-языках почти все по ссылке передается. Уж АлТД всегда обязаны по ссылке передаваться. Но проблем нет.

EC>Ты смешиваешь семантику и детали реализации.

Ага. Меня вообще не трогают вакуумные сфероконики.

EC>То что что-то передаётся посредством указателя ещё не значит, что значения типа имеет ссылочную семантику.

А меня не трогают заумности. Если указатель есть, то и тормоза от доступа по нему будут.

EC>Чтобы обозначить, что значение может отсутствовать используют Maybe, причём само значение типа Maybe не может быть null.
EC>Если бы ссылочная семантика присутствовала, то с чего бы вдруг Maybe понадобился?

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

VD>>А Хаскеле только она и есть. Причем ссылочность там трехэтажная. Просто нет налов.

EC>Можешь пример привести ссылочности в Haskell?

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

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

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

S>>Мир несовершенен. Тебе один хрен может прийти null "снаружи" — ведь не весь код написан на новой технологии.

VD>Это почему же это? Если что всегда можно сделать обертку которая проверит параметры "внешнего" метода на нал и переведет нас в координаты правильной системы типов. Ну, что-то вроде интеропа в дотнете.
Совершенно верно. И если параметр оказался нал, то что? Правильно, NPE. Но только NPE возникнет не в недрах нашего кода, через неопределенное время после поступления в него, а сразу же при попытке пересечь границы нашей системы. Ну либо там будет стоять сразу же проверка на null и корректная реакция.
VD>Читай внимательнее. Для этого есть option[T].
Да нормально я читаю. Мы говорим об одном и том же.
S>> Заметь, во второй шарп ввели Nullable типы ровно для тех, у которых нулла вовсе не было. Значит — есть спрос!
VD>Заметил. Мой вывод был однозначинй — уроды!
Очень странно. Nullable<int> — это ровно тот же option[int], вид сбоку.
Есть два способа привести от int? к int: безопасный и небезопасный.
Вот метод грубой силы:

int? n = null;
int a = (int)n;

Мы получим NPE.
Вот безопасный метод в более похожем на Nemerle стиле:

int? n = null;
int a = n ?? 0;

Чего не хватает в дотнете — это обратной штуки для reference-типов. Точнее, ее можно сделать самому, но без поддержки со стороны компилятора ее полезность близка к нулю.
Я склонен согласиться, что имело бы смысл и для референс типов сделать non-nullable тип основным, а возможность использовать null нужно было бы указывать явно.
VD>А я вот увер, что нет. Ну, или не подумал как следует. Попробуй перечитать все сказанное еще рез. Уверен, что ты поймешь о чем я говорю.
Влад, я всё уже прочитал и понял.

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

VD>А меня не трогают заумности.
Где ты там заумность увидел?
Вообще странно такое слышать от человека участвующего в разработке компилятора

VD>Если указатель есть, то и тормоза от доступа по нему будут.
Неужели? Т.е. передача структуры по ссылке в .NET это тормоза?
Это как минимум не медленнее чем передавать её по значению.
Или там указатель не используется?

EC>>Можешь пример привести ссылочности в Haskell?

VD>Любая переменная, любая функция. Ленивость хаскеля просто не оставляет никаких шансов кроме как заводить их в куче и управлять ими через ссылки.
Это к ссылочности не имеет никакого отношения. Пример не в кассу.

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

S>Очень странно. Nullable<int> — это ровно тот же option[int], вид сбоку.

Отнюдь.

S>Есть два способа привести от int? к int: безопасный и небезопасный.

Дык, а способов привести option[T] к T существовать не должно. Вообще!

В общем, проще перечислить различия:
1. При использовании option[T] тип T может быть любым (в том числе ссылочным и option[Х]). Тип T? может быть только вэлью-типом.
2. Не должно существовать способов обратиться к значению T кроме как специального защищающего оператора вроде match (паттерн-матчинга) или guards (из оберона).

S>Вот безопасный метод в более похожем на Nemerle стиле:
S>

S>int? n = null;
S>int a = n ?? 0;
S>

А если нет приемлемого значения по умолчанию или просто неохота с ним связываться?

Оперто ?? конечно хорош, но хорошо бы иметь возможность сделать так:

match (n)
{
  | Some(x) => исполььзуем значение ищ n (теперь оно доступно через x)
  | None    => делаем что-то в случае если n не содержит значения (или ничего не делаем).
}

S>Чего не хватает в дотнете — это обратной штуки для reference-типов. Точнее, ее можно сделать самому, но без поддержки со стороны компилятора ее полезность близка к нулю.

Да не должно быть разницы для ссылочных типов. Просто option[T] обязан допускать любой T, без ограничений. И именно по этому те кто делали нулабл-вэлью — уроды. Сколько раз я нарывался на то, что немогу написать простой обобщенной функции только из-за этого ограничения?!

S>Я склонен согласиться, что имело бы смысл и для референс типов сделать non-nullable тип основным, а возможность использовать null нужно было бы указывать явно.

Вот именно. И тода уж можно было бы вообще забыть про само понятие null, заменив его понятием необязательного значения.

S>Влад, я всё уже прочитал и понял.

Замечательно.

ЗЫ

Вообще, создатели современных мэйнстрим-языков очень зря "пропустили мимо ушей" некоторые решения из функционального мира. Функциональные типы, option-значения, паттерн-матчинг, аглеброические типы — это то, что обязательно надо ввести в ЯП, чтобы он был современным. Очень жать, что они понимают это слишком поздно. Это приводит к грязным решениям. Такие фичи нужно учитывать при проектировании ЯП и рантаймов.

Что то больно похоже что это борьба с симптомами а не с причиной заболевания.