Add get(string, index, default)

[staticfloat]

I think it would be nice to provide this functionality with a wider set of collections. With this change we now get:

julia> get("Julia", 1, ' ')
'J': ASCII/Unicode U+004a (category Lu: Letter, uppercase)

julia> get("Julia", 20, ' ')
' ': ASCII/Unicode U+0020 (category Zs: Separator, space)

julia> get("Julia", -5, ' ')
' ': ASCII/Unicode U+0020 (category Zs: Separator, space)

[ararslan]

I would make the index check isvalid(s, i)

[staticfloat]

Nice, I tried checkbounds() but that throws an error. isvalid() works great.

[nalimilan]

Good idea. Can you add a test?

[nalimilan]

Probably worth testing that the default is returned when indexing at a position which is within the bounds of the string, but doesn't correspond to the beginning of a character?

[staticfloat]

Excellent. This is exactly the kind of sideways thinking I want when I open a PR. Addressed in my new squashed commit.

[nalimilan]

Cool! But there's some spacing issue which made the CI fail.

[StefanKarpinski]

This feels a bit undermotivated to me. Was there an actual use case here?

[staticfloat]

I don't remember the original use case for this, but it seems a good tool for defensive programming. It allows me to do things like write verbs such as "split paragraph X into sentences, then take the 2nd character of the 3rd word" in a way that allows me to treat failure paths the same between characters in a word vs. words in a sentence.

[StefanKarpinski]

Eh, sure. If there's even a vague motivation for it, I guess it's ok. It treats indexing into the middle of a character the same as out-of-bounds indexing, however, which seems pretty sketchy to me.

[staticfloat]

While that's true, the purpose behind get(collection, index, default) always seemed to me to be "give me collection[index] and if anything goes wrong, return default". If we need ways to disambiguate different failure modes, we should probably come up with a different API than this simple get() method.

[StefanKarpinski]

the purpose behind get(collection, index, default) always seemed to me to be "give me collection[index] and if anything goes wrong, return default".

I don't think that's quite true – there's a difference between asking about a nonsense index and asking about an index that makes sense but doesn't exist. Again, an actual motivating use case would help understand what to do here.

[staticfloat]

there's a difference between asking about a nonsense index and asking about an index that makes sense but doesn't exist.

I agree with you; these are two different classes with errors that have different meanings. What I'm saying is that if your API only takes in collection, index, default, then to me it makes sense that the contract the API provides is "no matter what error I encounter, I will only ever return collection[index] or default". If you need something that is finer grained than this, then you should be using a different API. I see it similarly to wrapping code in try ... end; the contract here is no matter what goes wrong, don't throw an exception. If you want an exception, use a different API, e.g. try ... catch ... end.

I agree that indexing into the middle of wide characters is fundamentally a very different failure mode than indexing off the end of a string, but from the try ... end standpoint, it's just another error.

Seeing as this is a pretty simple case, I would suggest that if someone wants to differentiate between the different errors, they should just deal with those directly, and not use the get(collection, index, default) API.

[TotalVerb]

For what it's worth

julia> A = []
0-element Array{Any,1}

julia> get(A, "foo", 0)
ERROR: MethodError: no method matching get(::Array{Any,1}, ::String, ::Int64)
Closest candidates are:
  get(::ObjectIdDict, ::Any, ::Any) at associative.jl:541
  get(::Base.EnvDict, ::AbstractString, ::Any) at env.jl:79
  get(::AbstractArray, ::Integer, ::Any) at abstractarray.jl:1032
  ...

[nalimilan]

I think we should know the concrete use case before making a decision.

In general, I don't see in what case it would be legitimate to call get with an index which points in the middle of a code point and expect to get default. This kind of behavior is likely to hide bugs for people who don't take care of handling Unicode properly. We could return default only when the index is out of bounds, not when it is inside the bounds but invalid.

[StefanKarpinski]

I changed this in #24999: it now returns the default if you use an out-of-bounds index and throws an error if you use an invalid, in-bounds index.