Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added eltype(itr::EachLine) #6114

Closed
wants to merge 1 commit into from
Closed

Conversation

ivarne
Copy link
Sponsor Member

@ivarne ivarne commented Mar 11, 2014

The type returned from readlines is Array{Any,1}, and the EachLine iterator does not specify an element type. This PR attempts to fix those two issues.

There is still an issue with the way list comprehensions are used in collect that makes the inferred type from readlines wider than necessary (Union(Array{String,1},Array{Union(UTF8String,ASCIIString),N})).

Not sure if that is an issue that should be reported elsewhere.

Also reimplemented one argument readlines() with collect.
@@ -226,6 +226,11 @@ function done(itr::EachLine, nada)
true
end
next(itr::EachLine, nada) = (readline(itr.stream), nothing)
eltype(itr::EachLine) = String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't readline always return a ByteString?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think so, as ByteString == Union(UTF8String,ASCIIString). Is there a lot of benefit using a Union instead of an abstract as type of an array?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt it matters much in practice, but my instinct was to declare the narrowest correct type on general principles.

@JeffBezanson
Copy link
Sponsor Member

I forgot about the trailing function arguments to readlines. This is not documented and I can't find any uses of it either. @StefanKarpinski can we remove it?

@JeffBezanson
Copy link
Sponsor Member

Another potential application of @typeof:

eltype(itr) = @typeof(next(itr,start(itr))[1])

@ivarne
Copy link
Sponsor Member Author

ivarne commented Mar 12, 2014

Wouldn't @typeof be different from other macros, in that it will have to execute at a later stage? Ref: #3706

@ivarne ivarne deleted the EachLine branch March 12, 2014 21:22
@JeffBezanson
Copy link
Sponsor Member

It would just be a hook to generate a special type of expression. If the argument is not to be evaluated, you pretty much need something like that.

@ivarne
Copy link
Sponsor Member Author

ivarne commented Mar 12, 2014

Similar to the julia side of the definition of the @inbounds macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants