Julia's Release Process

Internals & Design
14

or Base.@propagate_inbounds or Base.@pure…

I also want to add that it is not only too narrow but also not enough. For example, show(io, "text/plain", x) pretty-prints x in a human readable form. But is Base/stdlib allowed to improve readability? If the exact output is documented to be a stable API, it is impossible. (See also: Version doctests · Issue #1050 · JuliaDocs/Documenter.jl · GitHub)

Another example is that, say there is a custom vector type in a stdlib:

struct CustomVector{T} <: AbstractVector{T}
    ...
end

is it backward compatible to add one more type parameter?

struct CustomVector{T, S} <: AbstractVector{T}
    ...
end

It is compatible for user defining function f(::CustomVector{Int}) but it is not for the usecase like

struct MyStruct{T}
    x::CustomVector{T}
end

because the field x will be boxed when a type parameter is added. IMHO Julia documentation should explicitly say that parametrized struct type must never be considered concrete. This means that you need to write

struct MyStruct{T, X <: CustomVector{T}}
    x::X
end

when performance matters. It also would be nice that each struct docstring defines what type parameters are considered public. The rule “parametrized struct type is not concrete” lets implementers hide some type parameters as implementation details. Another approach would be to say that only abstract types should be used for dispatch.

3 Likes