comprehensions element type: syntax extension proposal

[carlobaldassi]

If I got it right, comprehensions default to arrays of type Any whenever the type of the elements cannot be inferred at the time of parsing.
Apart from the issues with global variables (#524), there seems to be some unexpected behaviour in other cases, too:

[i | i = 1 : 4 ]
[i | i = 1 : (2 * 2) ]

all yield Vector{Int}, but

[i | i = 1 : 2^2 ]

yields Vector{Any}. It is easy to forget that a conversion is needed after a comprehension, and I suspect that building Array{Any}'s just to convert them later is a waste of resources.

Maybe it would be useful to provide some syntax to instruct the parser about what type to expect for the newly created array elements; for example, mimicking mathematical notation { i ∈ ℕ | ... } something like [ i in Int | ... ]. The keyword in fits nicely in that it is already taken, and its meaning is non-ambiguous for the parser, coming right before the | marker. The parser would discard the information if redundant (i.e. if it can already infer the type by itself, thus keeping the current behaviour), or trigger element-by-element conversions for concrete types, or just attach type-assertions for abstract types.

[JeffBezanson]

Optional declarations already do exactly this:

julia> [i::Int | i = 1 : 2^2 ]
[1, 2, 3, 4]

julia> typeof(ans)
Array{Int64,1}

So no new features are needed.

[carlobaldassi]

Oops, I did try that before but got an error because of a typo! Sorry :-/