String should be officially immutable & "abc" === "abc"

[StefanKarpinski]

As of 0.6, you can no longer do "abc".data and access a mutable Vector{UInt8} of the underlying bytes for a string. In 1.0 it would be desirable to have String object be truly immutable and have "abc" === "abc".

[yuyichao]

The way I want to implement this is vararg elements (similar to C variable length array elements). It can replace the special case for svec and string and also make strings more ABI comparible with C (the usefulness of that is a different question).

With the ref def and ops in #21912 it should be possible to implement the surface API.

[tkelman]

You can still mutate strings on 0.6, just not by the previous .data name

julia> a = "abc"
"abc"

julia> v = Vector{UInt8}(a)
3-element Array{UInt8,1}:
 0x61
 0x62
 0x63

julia> v[2] = 0x50
0x50

julia> a
"aPc"

[yuyichao]

FWIW, doing this might actually make "abc".data accessible again, though it won't be a Vector{UInt8}.

[sbromberger]

You can still mutate strings on 0.6, just not by the previous .data name

This confuses me a bit. Why should this work, but

julia> push!(v, 0x50)
4-element Array{UInt8,1}:
 0x61
 0x62
 0x63
 0x50

julia> a
"abc"

not impact a?

[StefanKarpinski]

You can still mutate strings on 0.6, just not by the previous .data name

Yes, but that need not be the case in 1.0. Having genuinely immutable Strings has many advantages, and we're very well positioned to make such a change since it's already atypical to mutate them. There will always be some ways to mutate strings since you can always poke at memory, but as long as we make it sufficiently hard / put up dire enough warning signs, it's ok.

[yuyichao]

This confuses me a bit. Why should this work, but

Neither is defined behavior.

[sbromberger]

@yuyichao ok, but what impact does it have? My interest is also security-related. What happens to that extra byte with respect to a?

[KristofferC]

@yuyichao What command causes undefined behaviour here?

julia> v = Vector{UInt8}(a)
3-element Array{UInt8,1}:
 0x61
 0x62
 0x63

julia> v[2] = 0x50
0x50

My point is, there is no unsafe-stuff used so doing this should be allowed.

[yuyichao]

My point is, there is no unsafe-stuff used so doing this should be allowed.

There's no unsafe-stuff used so doing this shouldn't crash.

[yuyichao]

What happens to that extra byte with respect to a?

Unrelated

[KristofferC]

Is there any docs what is undefined behaviour then? Like modifying an array from a string.

[sbromberger]

Unrelated

can you elaborate? If v is sort of a view into a (that is, &v == &a?), then what happens here? After the push, I cannot mutate a via v any more:

julia> a = "abc"
"abc"

julia> v = Vector{UInt8}(a)
3-element Array{UInt8,1}:
 0x61
 0x62
 0x63

julia> push!(v, 0x50)
4-element Array{UInt8,1}:
 0x61
 0x62
 0x63
 0x50

julia> a
"abc"

julia> v[2] = 0x50
0x50

julia> a
"abc"

[mbauman]

Resizing the vector forced a re-allocation:

julia> a = "abc"
"abc"

julia> v = Vector{UInt8}(a)
3-element Array{UInt8,1}:
 0x61
 0x62
 0x63

julia> pointer(v)
Ptr{UInt8} @0x000000011bf6f138

julia> push!(v, 0x50)
4-element Array{UInt8,1}:
 0x61
 0x62
 0x63
 0x50

julia> pointer(v)
Ptr{UInt8} @0x000000011be71b58

[sbromberger]

@mbauman that's really interesting; thanks. This is too:

julia> pop!(v)
0x63

julia> a
"ab\0"