It was probably an oversight. Why don't you open an issue, and perhaps a pull request?
Note that there are deeper/cleaner ways to solve the problem than simply falling back on SharedArray(T,x). The goal is to move away from that type of construct, I believe. That said, a pull request with that change would be a great start. Cheers! Kevin On Fri, Oct 9, 2015 at 7:06 AM, cheng wang <[email protected]> wrote: > Sorry, my second function is wrong. > > The following solves the problem. > call{T}(::Type{Base.SharedArray{T}}, x::Int64) = SharedArray(T, x) > > > On Friday, October 9, 2015 at 3:12:57 PM UTC+2, cheng wang wrote: >> >> Hello everyone, >> >> For example, In julia 0.4, SharedArray{Int}(100) does not work, while >> Array{Int}(100). >> It's kind of inconsistency, though we could get around it by >> SharedArray(Int, 100). >> >> Is there any particular reason for not having SharedArray{T}() >> constructor? >> >> >> And I also tried to define a new constructor for SharedArray like the >> follow: >> 1. SharedArray{T}(x::Int) = SharedArray(T, Int) or, >> 2. call{T}(Type{Base.SharedArray{T}}, x::Int64) = SharedArray(T, x) >> Both are illegal. The first one is because T is not used in parameters. >> and the second one is because "Type{Base.SharedArray{T}}" is invalid. >> >> But intuitively, I thought both should be right. Can someone also explain >> this? >> >> Thanks in advance! >> >
