在Julia中实现Option函子：如何保障类型稳定性？

一、更简洁的Option类型构造方式 #

你当前的定义可以简化，无需额外的MyNothing抽象类型，直接通过参数化结构体和Union类型即可实现带类型信息的Option：

# 定义带类型参数的None
struct None{T} end
# 定义Option为Some{T}和None{T}的联合类型
Option = Union{Some{T}, None{T}} where {T}

如果需要更明确的类型绑定，也可以写成Option{T} = Union{Some{T}, None{T}}，这样在声明变量类型时可以指定具体的T，比如x::Option{Int}。

二、fmap函数的类型稳定实现 #

你之前用Base.return_types导致类型不稳定的问题，可以通过多重分派+编译时类型推断解决，无需依赖复杂的trait或运行时类型提取逻辑：

实现方案 #

利用Julia的多重分派特性，分别为None{T}和Some{T}实现fmap方法，通过Core.Compiler.return_type在编译时推导函数返回类型：

# 针对None{T}的fmap实现：编译时推导返回类型
function fmap(f, ::None{T}) where {T}
    # 获取f在输入类型T时的返回类型
    ReturnType = Core.Compiler.return_type(f, Tuple{T})
    None{ReturnType}()
end

# 针对Some{T}的fmap实现：直接映射函数到内部值
function fmap(f, s::Some{T}) where {T}
    Some(f(s.value))
end

# 适配你原有的Functor包装调用方式
function fmap(::Functor{Option}, obj, fun)
    fmap(fun, obj)
end

优势说明 #

1. 类型稳定性：Core.Compiler.return_type是编译时的类型推断工具，比运行时的Base.return_types更可靠，能让Julia编译器确定返回值的具体类型，避免Any类型的出现。
2. 简洁性：去掉了复杂的param_type和outtype逻辑，直接利用Julia的类型系统特性实现。
3. 通用性：无需依赖类型的默认值（如zero(T)），即使是自定义无默认值的类型也能正确推导返回类型。

内容的提问来源于stack exchange，提问作者David Reynolds