Чтобы расширить ответ от J. Blauvelt, упущение convert(Int, d)
является преднамеренным. Причина в том, что convert
часто подразумевает эквивалентность и используется автоматически при добавлении элементов в контейнеры:
julia> c = [1,2]
2-element Array{Int64,1}:
1
2
julia> push!(c, Second(5))
ERROR: MethodError: Cannot `convert` an object of type Second to an object of type Int64
Closest candidates are:
convert(::Type{T<:Number}, ::T<:Number) where T<:Number at number.jl:6
convert(::Type{T<:Number}, ::Number) where T<:Number at number.jl:7
convert(::Type{T<:Integer}, ::Ptr) where T<:Integer at pointer.jl:23
...
Stacktrace:
[1] push!(::Array{Int64,1}, ::Second) at ./array.jl:853
[2] top-level scope at none:0
Если вы разрешите этот вид автоматического преобразования, вы можете запутаться: например, push!(c, Day(5))
также поместит 5
в c
, и внезапно вы окажетесь в ситуации, когда вы подразумеваете, что Day(5) == Second(5)
.
Теперь синтаксис конструктора Int(t)
отличается от convert(Int, t)
. Так что в принципе, возможно, это могло быть разрешено. Но исторически эти два были переплетены, и может быть значительное количество кода, который не различает два.
Следовательно, когда вы запрашиваете что-то, связанное с внутренним представлением , сейчас кажется, что лучше потребовать, чтобы пользователь использовал это представление напрямую (например, t = Second(5); t.value
). Или напишите свой код так, чтобы вы могли хранить эти значения вместе с их единицами.