Внутренние конструкторы параметрического составного типа в Юлии: зачем `где {T}`? - PullRequest
Новая
       21

Внутренние конструкторы параметрического составного типа в Юлии: зачем `где {T}`?

1 голос
/ 25 марта 2019

Почему это повышает LoadError: UndefVarError: T not defined: 

struct Point{T}
    x::T
    y::T
    Point{T}(x,y) = new(x,y)
end

пока все работает нормально: 

struct Point{T}
    x::T
    y::T
    Point{T}(x,y) where {T} = new(x,y)
end

Кажется, что когда-то они оба были в порядке: Внутренний конструктор параметрического типа

РЕДАКТИРОВАТЬ: Чтобы уточнить, я ожидал, что тот факт, что мы находимся в блоке struct Point{T}, прояснил, что T относится даже в первом случае.

1 Ответ

2 голосов
/ 25 марта 2019

Без where предложение T унаследовано от глобальной области (что довольно удивительно, но вот как это работает): 

julia> T = String
String

julia> struct Point{T}
           x::T
           y::T
           Point{T}(x,y) = new(x,y)
       end

julia> Point{String}("b","a")
Point{String}("b", "a")

julia> Point{String}(SubString("b",1,1),SubString("a",1,1))
Point{String}("b", "a")

julia> Point{Int}(1, 2)
ERROR: MethodError: no method matching Point{Int64}(::Int64, ::Int64)

julia> Point{String}(1, 2)
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type String

РЕДАКТИРОВАТЬ

Короткий ответ, учитывая комментарии к Дискурсу, заключается в том, что причина этого в том, что T из struct в настоящий момент неизвестен, когда вызывается внутренний конструктор.

...