What's Base.Int and Base.UInt32_cold? And will former (both?) "change or be removed in future versions"?

I noticed Base.Int in code and it seems Base. prefix is redundant, but:

help?> Base.Int
│ Warning

│ The following bindings may be internal; they may change or be removed in future versions:

│ • Base.Int

Note unlike for Core.Int, seemingly another synonym with no such warning. All three otherwise have same text.

There’s also in the codebase in a struct:
isSigned::Base.Bool

is it just out of habit or in some sense meaningful/better in some [struct] code? [Note, Base.length has no warning, also redundant to use there…]

At first I was just looking at this line:

const ZSTD_COMPRESSOR = Lockable{ZstdCompressor}[]

and there apparently Base. actually missing, since Base.Lockable actually only exported in 1.12, so unclear why also working in 1.11 (even before when absent? I do not see Compat.jl used).

Should Lockable be made public, since it’s used? That started this investigation…

Never thought to check, but Base.Int, Base.Int32, Base.Float64, etc all are non-public names that happen to be assigned to same objects as the original Core names. ?Main.# doesn’t show that, so that suggests Base assigns Core types instead of importing, despite having an export list in exports.jl that suggests reexporting all these names from Core. No idea where or why.

Not really sure if you meant to talk about UInt32_cold(c::Char) = UInt32(c) because the rest of the topic doesn’t address it, but I’m pretty sure “cold” is an informal hint of a rarely executed path, opposite of a hot path. As for being a separate function, it appears to be marked @noinline, so it probably just helps limit the compiled code size of the caller function.

1 Like