improve return type inference for string
#52806
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Packages like URIs.jl overload `joinpath` with methods that return non-strings. This prevents good return type inference for `string` when the types of its arguments are unknown. Even if this is a URIs.jl bug, it makes sense to be defensive about this in the Julia implementation. Also note that URIs.jl is widely-used, JuliaHub says it's got in excess of a thousand (indirect) dependents. So, IMO, this is a Julia bug that we should fix: ```julia-repl julia> all(T -> T <: AbstractString, Base.return_types(string)) true julia> import URIs julia> all(T -> T <: AbstractString, Base.return_types(string)) false ``` Fixed by adding a `::String` type assertion in `base/libdl.jl`.
MasonProtter
suggested changes
Jan 8, 2024
| @@ -334,7 +334,7 @@ struct LazyLibraryPath | |||
| LazyLibraryPath(pieces::Vector) = new(pieces) | |||
| end | |||
| LazyLibraryPath(args...) = LazyLibraryPath(collect(args)) | |||
| Base.string(llp::LazyLibraryPath) = joinpath(string.(llp.pieces)...) | |||
| Base.string(llp::LazyLibraryPath) = joinpath(string.(llp.pieces)...)::String | |||
There was a problem hiding this comment.
Not sure this is a good idea, but if you want to do it, it should be a return type declaration, so
Suggested change
| Base.string(llp::LazyLibraryPath) = joinpath(string.(llp.pieces)...)::String | |
| Base.string(llp::LazyLibraryPath)::String = joinpath(string.(llp.pieces)...) |
There was a problem hiding this comment.
Not sure this is a good idea
Why would it be anything but good? There's basically no downside. In case the check is useless, it will get optimized out, otherwise it's useful because it helps contain type-instability.
if you want to do it, it should be a return type declaration
Why? As far as I see the expression joinpath(string.(llp.pieces)...) is required to be a String, not just convertible to String, so I don't see a good reason for introducing conversion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Packages like URIs.jl overload
joinpathwith methods that return non-strings. This prevents good return type inference forstringwhen the types of its arguments are unknown. Even if this is a URIs.jl bug, it makes sense to be defensive about this in the Julia implementation. Also note that URIs.jl is widely-used, JuliaHub says it's got in excess of a thousand (indirect) dependents.So, IMO, this is a Julia bug that we should fix:
Fixed by adding a
::Stringtype assertion inbase/libdl.jl.