I can't see any argument for why it would be wrong to add the requested
method. Please open an issue (or better yet a Pull request) on github, so
that we can have more opinions on the matter.
The implementation could be as simple as
*convert{T<:AbstractString}(::Type{T}, c::Char) = convert(T, string(c))*
but we probably want a more efficient approach that doesn't allocate a
IOBuffer to create a single character string. (in testing this I also
discovered that we are missing convert(::Type{SubString}, a::ASCIIString),
and that might also be quite trivial to implement and somewhat useful)
We are in the process of changing a few fundamentals about how strings
works internally, so it is really important that we include tests for the
new behaviour so that it isn't forgotten in the rewrite.
Ivar
kl. 02:25:53 UTC+1 onsdag 7. januar 2015 skrev [email protected] følgende:
>
>
>
> On Wednesday, January 7, 2015 10:51:54 AM UTC+10, Ronald L. Rivest wrote:
>>
>> Using Julia 0.3.4. The following seems somehow inconsistent. Is there
>> something about the philosophy of `convert` I am missing??
>>
>> *julia> convert(ASCIIString,'a')*
>>
>> *ERROR: `convert` has no method matching convert(::Type{ASCIIString},
>> ::Char)*
>>
> Char is a Unicode codepoint so it cannot be guaranteed to be convertable
> to ASCIIString. But you could argue that conversion to UTF8String (or
> other unicodes) should work, but at least in 0.3.4 it doesn't.
>
> Cheers
> Lex
>
>
>> * in convert at base.jl:13*
>>
>> *julia> string('a')*
>>
>> *"a"*
>>
>> *julia> typeof(ans)*
>>
>> *ASCIIString (constructor with 2 methods)*
>>
>> Cheers,
>>
>> Ron
>>
>
