# String7 and Bools : bug or feature?

**URL:** <https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188>\
**Category:** General Usage\
**Tags:** csv\
**Created:** [July 4, 2023, 9:21pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188 "2023-07-04T21:21:36Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Joris\_Pinkse](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joris_pinkse/32/216398_2.png) [@Joris\_Pinkse](https://discourse.julialang.org/u/Joris_Pinkse)\
**Post date:** [July 4, 2023, 9:21pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/1 "2023-07-04T21:21:36Z")

</div>

This one got me (by reading in a DataFrame via CSV).

Is this behavior intentional?

```julia

julia> using CSV

julia> x = String7( "4" )
"4"

julia> parse( Int, x )
4

julia> y = String7( "true" )
"true"

julia> parse( Bool, y )
ERROR: InexactError: Bool(10)
Stacktrace:
 [1] Bool
   @ ./float.jl:158 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
   @ Base ./parse.jl:126
 [4] parse(::Type{Bool}, s::String7; base::Nothing)
   @ Base ./parse.jl:241
 [5] parse(::Type{Bool}, s::String7)
   @ Base ./parse.jl:240
 [6] top-level scope
   @ REPL[5]:1

julia> z = String( y )
"true"

julia> parse( Bool, z )
true

```

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [July 4, 2023, 9:45pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/2 "2023-07-04T21:45:43Z")

</div>

> [@Joris\_Pinkse](#):
>
> `parse( Bool, y )`

`String7` belongs to the `InlineStrings` package. ~~I guess this is an `InlineStrings` bug, however, it’s fixed in the latest version, v1.4.0, of `InlineStrings`.~~

~~What’s your version of InlineStrings? Try updating and see if it fixes the bug.~~

---

<div class="post-metadata">

**Author:** ![Joris\_Pinkse](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joris_pinkse/32/216398_2.png) [@Joris\_Pinkse](https://discourse.julialang.org/u/Joris_Pinkse)\
**Post date:** [July 4, 2023, 9:57pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/3 "2023-07-04T21:57:05Z")

</div>

It doesn’t appear to be fixed in v1.4.0.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [July 4, 2023, 10:16pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/4 "2023-07-04T22:16:50Z")

</div>

I can confirm the error for InlineStrings 1.4.0. Incidentally, my related package StaticStrings.jl also has the same issue.

```julia
julia> parse(Bool, inline"true")
ERROR: InexactError: Bool(10)
Stacktrace:
 [1] Bool
   @ ./float.jl:171 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
   @ Base ./parse.jl:126
 [4] parse(::Type{Bool}, s::String7; base::Nothing)
   @ Base ./parse.jl:241
 [5] parse(::Type{Bool}, s::String7)
   @ Base ./parse.jl:240
 [6] top-level scope
   @ REPL[33]:1

julia> parse(Bool, inline"true"; base=2)
ERROR: InexactError: Bool(2)
Stacktrace:
 [1] Bool
   @ ./float.jl:171 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
   @ Base ./parse.jl:126
 [4] parse(::Type{Bool}, s::String7; base::Int64)
   @ Base ./parse.jl:241
 [5] top-level scope
   @ REPL[34]:1

julia> using StaticStrings

julia> parse(Bool, static"true"; base=2)
ERROR: InexactError: Bool(2)
Stacktrace:
 [1] Bool
   @ ./float.jl:171 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] tryparse_internal(#unused#::Type{Bool}, s::StaticString{4}, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
   @ Base ./parse.jl:126
 [4] parse(::Type{Bool}, s::StaticString{4}; base::Int64)
   @ Base ./parse.jl:241
 [5] top-level scope
   @ ~/.julia/packages/StaticStrings/oSXOl/src/macros.jl:19

```

The problem appears to be related to the `base`.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [July 4, 2023, 10:18pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/5 "2023-07-04T22:18:34Z")

</div>

`Meta.parse` seems to work just fine though.

```julia
julia> Meta.parse(static"true")
true

julia> Meta.parse(inline"true")
true

```

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [July 4, 2023, 10:22pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/6 "2023-07-04T22:22:50Z")

</div>

Sorry, this was a Julia Base bug, it has been fixed seven months ago, but I guess the fix wasn’t backported to any releases:

> <https://github.com/JuliaLang/julia/pull/47782>
>
> Fixes https://github.com/JuliaStrings/InlineStrings.jl/issues/57.
> 
> We currentl…y have a specialization for \`parse(Bool, ::Union{String, SubString{String})\` where \`true\` and \`false\` are parsed appropriately. The restriction to \`Union{String, SubString{String}}\`, however, means we don't get this behavior for other \`AbstractString\`s. In the linked issue above, for InlineStrings, we end up going through the generic integer parsing codepath which results in an \`InexactError\` when we try to do \`Bool(10)\`.
> 
> The proposal in this PR takes advantage of the fact that there is only the 2 comparisons where we do \`\_memcmp\` that require the input string to be "dense" (in memory), and otherwise, we just do a comparison against a \`SubString\` of the input string.
> 
> Relatedly, I've wanted to introduce the concept of an abstrac type like:
> 
> \`\`\`julia
> abstract type MemoryAddressableString \<: AbstractString
> \`\`\`
> 
> where the additional required interface would be being able to call \`pointer(::MemoryAddressableString)\`, since a lot of our string algorithms depend on doing these kind of pointer operations and hence makes it quite a pain to implement your own custom string type.

`parse` certainly works for me on nightly Julia.

---

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [July 7, 2023, 3:34pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/7 "2023-07-07T15:34:07Z")

</div>

This should be fixed in 1.6.8, 1.8.5, 1.9.3, and 1.10.0 (none of which have been released atm)

[Edit: corrected]

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [July 7, 2023, 4:36pm UTC](https://discourse.julialang.org/t/string7-and-bools-bug-or-feature/101188/8 "2023-07-07T16:36:26Z")

</div>

> [@Lilith](#):
>
> 1.9.2

Actually, v1.9.2 was released two days ago. I think you mean v1.9.3, because v1.9.2 still seems to be buggy.