typealias in local scope doesn't always throw an error

[neel]

type cell{T}
        possibilities::Array{T}
end
typealias cell_type1 cell{UInt64}
#^^ okay
type candidate{T}
        typealias cell_type cell{T}
end
#^^ ERROR: UndefVarError: T not defined

[yuyichao]

typealias should be a toplevel only expression and allowing it in some cases in type definition is only an accident since we don't check for that explicitly.

[yuyichao]

Also, this is kind of a dup of #12010 since that's what we lower this to. We do need a different error message though.

[neel]

What is wrong with local scope typealias ? If one cannot define parameterized types related to local scopes it will be difficult to manage if there are too many parameterized types.

[eschnett]

Local scope in functions is fine. Local scopes in a type declaration is currently a strange thing in Julia; it's not well defined what this is or what it should be. Within a type declaration you can (obviously) declare fields and constructors, but currently (strangely) a few other things as well -- but not type aliases.

In other words, if you move the typealias into the type constructor, things should work fine.

[neel]

putting the typealias on ctor will make it available only in the function scope but it is actually required in class scope to declare member variables.
Is there any kind of static method or static member variables ? Is it possible to use typeof on them ?

[StefanKarpinski]

It's kind of unclear what you're trying to accomplish and why you want typealias in local scope.

[yuyichao]

With the current "strange" local scope in type definitions, the only thing we actually support is local functions. If you just want a shorter name for a useful type (like how typedefs are used in C++ class definitions) you can accomplish that with functions or normal local variables too.

julia> type A{T}
           my_type(V) = Tuple{T,V}
           A{V}(v::my_type(V)) = new(v[1], V)
           x::T
           t::DataType
       end

julia> A{Int}((1, 1.2))
A{Int64}(1,Float64)

[neel]

I was trying to do something like we do for iterators or value_type in C++.

template <typename T>
struct X{
  typedef typename T::iterator iterator_type;
  typedef typename T::value_type value_type;
};

[eschnett]

In Julia, member functions (and member types) are defined outside the type's scope. static in C corresponds to taking a type as argument in Julia.

immutable X{T} end
iterator_type{T}(::Type{X{T}}) = iterator(T)
value_type{T}(::Type{X{T}}) = value_type(T)

Of course that's just a literal translation; the functions iterator and value_type have different names in Julia.

Note that these functions will be inlined and type-inferred in Julia, so that there is no overhead in doing so.

[tkelman]

close as dup of #12010 now that typealias is gone?

[JeffBezanson]

We only evaluate type definition blocks once at the top level, and generally don't have "parameterized blocks" of code, e.g. that would run for each value of T, except for method definitions. Related to #18466, since that could provide some way to get this. For example we don't currently allow:

struct Foo{T}
    vec = Vector{T}
    x::vec
    y::vec
end

as a shortcut for

struct Foo{T}
    x::Vector{T}
    y::Vector{T}
end

One reason is that the syntax a = b is reserved for a possible default field values feature. The other reason is that the various constructors that might exist inside the block cannot "share" parameters; each method definition is separate. However it is not common in julia to write lots of code inside type definition blocks; usually all methods and even most constructors are defined outside of it, so a feature for this would be of limited use anyway.