Let's take a look at each of these internal representations of code, and document which of the fields are relevant to each consumer. This is not necessarily the current state, but rather the intended future state. Definitions First we have Method: this seems fairly self-explanatory. This represents a user-defined dispatch entry target. Next we have MethodInstance: this is the pair of details: (Method, specialization types) which uniquely defines each object by egal and type-equality. Next we have CodeInfo: this describes a precise input to codegen. It might be unspecialized (just the direct output of code lowering) or optimized. It contains the statements of the function, and some metadata for each of the statements. It may contain some extra data unused by codegen, but generally that data may not be available. Next we have IRCode: this represents a superset of the information in CodeInfo, but also in particular represents it in a exploded way that is easier to mutate. The CodeInfo representation is optimized for size when compressed instead. It might not be easy to mutate this further (though it can be appoximately converted back to an IRCode with some effort)

History and motivation From its inception, Julia has had an Array type intended to be used any time you need "a bunch of things together in some order". This is one of the most important and most unusual types in the language. When Array was designed, it was believed (possibly by multiple people, but Jeff is willing to take the blame) that the easiest-to-use interface would be a single array type that does most of what users need. Many Julia programmers now feel that the language and community have outgrown this trade-off, and problems have emerged: Array has many features, with an unusually large amount of functionality written in C. This makes the code harder to maintain and harder for the compiler to optimize.

There has been talk lately of the idea that having using in programs is a problem, because it leads to breakage as programs change. However, using is not the problem here, and in fact, using is a very beneficial and useful feature. Where the problem comes from is when the exports of package change, they may end up colliding with exports from another package, leading to the dreaded "imports must be qualified" error. Rather than making peopled worried their code now needs a PhD to be qualified, we want to give people a tool to avoid the issue with conflicting imports directly: API versioning. Declaring an API version We already have the concept of program versions, but currently there is no way to indicate that at the granularity of an individual export. This proposal aims to change that, giving an optional mechanism that people can use to add new exports without needing to analyze if this will break other code. The first part of this proposal thus is extending the vocabulary for exports. Currently this only lists symbols. In this proposal, the vocabulary for export is extended to list version ranges and alternative (internal) names. First lets look at some examples for my sample package CoolCodes which is at v1.4 currently, then lets discuss what each piece means: module CoolCodes

new playground primitive type InteriorPtr sizeof(Ptr) end # Addrspace(Loaded) mutable struct ForeignMemory{T, atomic::Bool} <: AbstractVector{T} @atomic length::Int const data::InteriorPtr # => Vararg{T,length} # const types::IfElse{isbitsunion(T), InteriorPtr, Nothing} # => Vararg{UInt8,length} const owner::Any end mutable struct Memory{T, atomic::Bool} <: AbstractVector{T} @atomic length::Int

Aka #265 for types. For context see: https://github.com/JuliaLang/julia/issues/40399 Problem abstract: It has long been acknowledged a minor wort that once defined, any constant object in Julia cannot be replaced or redefined. There are some exceptions and workarounds to this, but this is generally a nuisance and a hindrance to developer productivity. A fix for the similar issue for functions, often called by its issue number as 265, was merged many years ago. This enabled some powerful new workflows, powered by the Revise.jl package. However, despite some initial efforts to remove the restriction on redefining constants, the work did not address the correctness and behavioral questions we will attempt to define here. To begin, lets start by considering all of the ways that users might refer to globals in their code: module ABetterDeveloper using AModule: AReplaceableExport as AReplacableImport const AReplaceableConstant = AReplaceableImport

Reasoning For performance. Simply that. Only that. Sample definition: @nospecialize abstract type Function _(args...) end # this is what we do now (in essence) @nospecialize abstract type IO read(_, Type{UInt8})::UInt8