You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only (definitional) criteria of DenseArray is that it's stored contiguously in memory.
We also have Codeunits <: DenseVector. However, there is no requirement that the string backing the codeunits are stored densely in memory. For example, InlineString.jl provide string types which are 8-byte primitives.
I'm not sure what to do about this. It might be breaking to remove Codeunits <: DenseVector, but it's also silly to have it subtype DenseVector when the only thing that matters about DenseVector is not upheld.
The text was updated successfully, but these errors were encountered:
CodeUnits(s::S) where {S<:AbstractString} =new{codeunit(s),S}(s)
end
Ooof, that's tricky. I guess we could try the simple thing — change it to AbstractVector — and check both of nanosoldier's reports. If we need to preserve CodeUnits{UInt8, String} <: DenseVector{UInt8} the realm of possible fixes (and their associated breakages) becomes much more complicated and the tradeoffs will be hard to evaluate.
The only (definitional) criteria of
DenseArray
is that it's stored contiguously in memory.We also have
Codeunits <: DenseVector
. However, there is no requirement that the string backing the codeunits are stored densely in memory. For example, InlineString.jl provide string types which are 8-byte primitives.I'm not sure what to do about this. It might be breaking to remove
Codeunits <: DenseVector
, but it's also silly to have it subtypeDenseVector
when the only thing that matters aboutDenseVector
is not upheld.The text was updated successfully, but these errors were encountered: