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

_C_>но ессно option[T] должна быть структурой по реализации, даже если ее удобно показывать как вариант.
_C_>иначе накладные расходы и странности в использовании.

Заинтересовался вопросом накладных расходов на класс по сравнению со структурой ещё из прошлого обсуждения в какой-то другой теме.
В некоторых модулях в рабочем проекте (правда на C#) активно используется самодельный Option вида:

public abstract class Option<T>: IEnumerable<T> {
    public abstract bool HasValue { get; }
    public abstract T Value { get; }
}

public sealed class Some<T>: Option<T> {
    ...
}

public sealed class None<T>: Option<T> {
    ...
}

Из любопытства проверил следующие варианты:
1. Option в реализации, приведённой выше
2. Option без наследования (то есть пустое поле под Value будет даже у None)
3. Option в виде структуры
4. Алгоритм вообще без Option

Дело было недели 3 назад, поэтому конкретных цифр, к сожалению, не осталось.
В целом, первые три варианта отличались совсем незначительно и по большей части разница была только в объёме используемой памяти и количестве сборок мусора.
Можно даже сказать, что вариант со структурами был несколько медленнее с точки зрения затраченного времени, но эффективнее в плане нагрузки на память и сборщик.
Вариант без Option'ов работал где-то процентов на 30-40 быстрее, чем с оными, но код при этом стал раза в 3 страшнее.