Unexpected behavior due to implicit `convert` with `Char` and `Integer`

[mzgubic]

julia> append!([1, 2, 3], "4")
4-element Vector{Int64}:
  1
  2
  3
 52

is unintuitive (I would expect an error).

I think the mechanism for this is that it treats the "4" as a collection of Chars, and converts them into integers.

cc @jakobnissen @andrewrosemberg @raphaelsaavedra

[jakobnissen]

To be more explicit about the issue, the problem is that convert is called implicitly, which is a recipe for bugs. To quote from the Julia documentation:

since convert can be called implicitly, its methods are restricted to cases that are considered "safe" or "unsurprising". convert will only convert between types that represent the same basic kind of thing (e.g. different representations of numbers, or different string encodings).

And I would argue that Char is not the same basic kind of thing as an integer. So the issue is really: For Julia 2.0, should we consider removing convert(::T, x::AbstractChar) where T <: Number and similar methods?

[Moelf]

For Julia 2.0, should we consider removing convert(::T, x::AbstractChar) where T <: Number and similar methods?

can we check all existing packages and deprecate it now? this sounds horrible to leave the usage build up

[timholy]

Some parsing relies on Char <-> Integer conversions. Check out the Base64 and CRC32 stdlibs sometime.

C and Rust allow this. Python and javascript make you jump through more hoops. I guess the argument is for more hoops?

[jakobnissen]

After having skimmed those stdlibs, I can't see how they rely on the conversion. To be clear, the idea is not to remove Int(::Char), only convert methods. The problem with convert is that it's called implicitly, and so can easily happen without the user realizing it.

[vtjnash]

Yes, if you make a PR and PkgEval is okay with this, it seems very safe to remove now.

[Moelf]

it would fail at bootstrapping if we don't have convert for Char <-> Number.

I honestly think Char <-> Number can be argued both ways. the real reason this append!() is confusing is because String is treated as a scalar in my mind (c.f. broadcast treat it as scalar) so append!() shouldn't work.

But do we want:

append!(::Array{Char}, ::String)

to work?

[KristofferC]

C and Rust allow this. Python and javascript make you jump through more hoops. I guess the argument is for more hoops?

This is about implicit conversions. Rust definitely doesn't allow something like 1 + 'a'. The argument is to have to be explicit and use a constructor, for example, 1 + Int('a').

Edit: I see this point has already been made in a reply. Oh well.

[jakobnissen]

@Moelf Perhaps the issue of "scalar versus iterable" aspect of strings can be separated out into its own issue? (Perhaps there are already issues on this). While both are at play in the example in OP, they are independent issues, I think.

[stevengj]

You could remove the implicit convert, but still have + and - methods like

julia> 'b' - 'a'
1

julia> 'a' + 1    # equivalent to 'a' + ('b' - 'a')
'b': ASCII/Unicode U+0062 (category Ll: Letter, lowercase)

which I admit that I like.