String: alias for new String or old UTF8String #192
Conversation
| @@ -1077,4 +1077,12 @@ if !isdefined(Base, :Threads) | |||
| export Threads | |||
| end | |||
|
|
|||
| if isdefined(Core, :String) | |||
There was a problem hiding this comment.
Maybe it's better to check VERSION >= 0.5.0-dev+3876
|
Updated to support 0.3 as well. |
| @@ -1077,4 +1077,12 @@ if !isdefined(Base, :Threads) | |||
| export Threads | |||
| end | |||
|
|
|||
| if isdefined(Core, :String) && isdefined(Core, :AbstractString) | |||
| typealias String Core.String | |||
| export String | |||
There was a problem hiding this comment.
I still don't understand why this is needed. I just tried running the latest 0.5, and String already seems to be exported.
There was a problem hiding this comment.
I guess we don't actually need it – it seems that you can import a binding from Compat that was inherited from Base.
There was a problem hiding this comment.
We don't need to import it from Compat in the first place, because you already get the symbol from Base anyway in 0.5.
There was a problem hiding this comment.
It's the wrong binding on 0.3 and 0.4 – you want to use a thing called String that is actually Base.UTF8String.
There was a problem hiding this comment.
On 0.3 and 0.4, you export the typealias. That part is fine. What I'm saying is that on 0.5, Compat can just do nothing (no exports, no typealiases).
People should be doing using Compat to get all of the exports (if any), not import Compat: String etcetera; the latter is not how the Compat module is supposed to work.
There was a problem hiding this comment.
See e.g. how AbstractString was handled.
There was a problem hiding this comment.
That won't work in this case since String is already defined and exported on both 0.3 and 0.4 – but it has a different meaning than the one we're exporting here. On 0.3, not doing the import works since at that point we just let the last export win. On 0.4, however, this will not work since we now do this:
julia> using Compat; String
WARNING: both Compat and Base export "String"; uses of it in module Main must be qualified
ERROR: UndefVarError: String not defined
in eval(::Module, ::Any) at ./boot.jl:236So the only way to write code that uses the name String to mean something UTF8String-like on all of 0.3, 0.4 and 0.5 is to do using Compat; import Compat.String and then use the name String. If you can think of some way around this, I'm all ears.
There was a problem hiding this comment.
can't @compat(String(...)) do a rewriting without messing with imports?
There was a problem hiding this comment.
Yes, but String types are so common that it is probably easier to do import than to sprinkle @compat all over the place.
|
What's the status of this? |
|
still needs tests, still needs docs, and I think Stefan is traveling at the moment |
* Depwarn for `readall` * Depwarn for `UTF8String` * Workaround error when using `esc` on function argument * Add Compat 0.7.14+ dependency
|
Bump. Would be nice to be able to start fixing packages. |
|
All the code required to start fixing packages is merged already: all you need to do is |
|
I tried to go ahead and fix some packages following the advice in #192 (comment) but it doesn't work. Right now on 0.4 I get julia> using Compat
julia> import Compat.String
julia> foo(x::String) = 1;
julia> foo("Hello")
ERROR: MethodError: `foo` has no method matching foo(::ASCIIString)
julia> methods(foo)
# 1 method for generic function "foo":
foo(x::UTF8String) at none:1 |
|
Right. you can't just replace |
|
But then I need to think. I tried to avoid that. |
|
Maybe we need |
|
Probably superseded by #197. |
Use Base.promote_op() for arithmetic operators
Closes #193.