It was *stated* that it could not be done, but not explained. Having `eltype()`

of a generator return the actual type *can* be done as I have shown in my first post. My solution may violate some theoretical principles, but in practice, the same solution is implemented in various places. @mbauman explained that type inference may be fragile and should be avoided, but what can be wrong with the following POC:

```
struct TypedGenerator{T}
g::Base.Generator
end
```

```
macro typed(ex)
if ex.args[1].head == :(::)
:(TypedGenerator{$(ex.args[1].args[2])}($ex))
else
ex
end
end
```

```
Base.iteratoreltype(::TypedGenerator{T}) where T = Base.HasEltype()
Base.eltype(::TypedGenerator{T}) where T = T
# Define iterator protocol methods delegating to `.g`.
```

```
julia> eltype(@typed (f(x) for x in 1:2))
Any
julia> eltype(@typed (f(x)::Int for x in 1:2))
Int64
```

If such code is acceptable in a user program, why would it be a bad idea for `(f(x)::Int for x in 1:2)`

to return a variant of `TypedGenerator{T}`

without the `@typed`

macro?

How would the user that knows the type of `f(x)`

and wants to provide that type in a generator expression `(f(x) for x in iter)`

actually do it? I suggest that `(f(x)::T for x in iter)`

is the first thing that comes to mind and if you subscribe to the principle of least surprise, the `eltype()`

of this expression should be `T`

.