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

convert & promote_rule for Char and strings #25728

Closed
StefanKarpinski opened this issue Jan 24, 2018 · 5 comments
Closed

convert & promote_rule for Char and strings #25728

StefanKarpinski opened this issue Jan 24, 2018 · 5 comments

Comments

@StefanKarpinski
Copy link
Member

Came up over here: #25515 (comment). I think we should consider adding something like:

promote_rule(::Type{Char}, ::Type{S}) where {S<:AbstractString} = S

convert(::Type{String}, c::Char) = string(c)
convert(::Type{S}, c::Char) where {S<:AbstractString} =
    convert(S, convert(String, c))

Previously when Char <: Integer this was considerably sketchier but that's not the case anymore.

@StefanKarpinski StefanKarpinski added the triage This should be discussed on a triage call label Jan 24, 2018
@nalimilan
Copy link
Member

That's tempting, but I'm not sure that's right to allow converting an entry into a one-element collection like that. Shouldn't we define == between strings and chars if we do that?

Do we have other use cases than accumulate(*, ['a', 'b'])? For example, ['a', "b"] would give ["a", "b"], which may or not be desirable.

@JeffBezanson
Copy link
Member

I think this is non-breaking?

@nalimilan
Copy link
Member

Changes to promotion affect the type of elements inside array literals, so I think it's breaking (though not terribly so).

@JeffBezanson
Copy link
Member

True.

I'm starting to think I'd prefer a slightly different approach to promotion in general. The only cases where I really want it are arithmetic, and mixed numeric array literals like [0, 0.5, pi]. It would be much simpler if we could say it's only for arithmetic, but AFAICT we need to have [0, 0.5] give a Float64 array or we'll have huge problems. Maybe special case array constructors where everything is a Number? I'm not even sure [[1], [1.0]] needs to give a homogeneous array result.

@StefanKarpinski StefanKarpinski removed the triage This should be discussed on a triage call label Jan 25, 2018
@StefanKarpinski
Copy link
Member Author

Triage: decided against.

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

No branches or pull requests

3 participants