Proposal: parametrize `FunctionField` by polynomial ring type, mirroring `RationalFunctionField`

[alexey-orlov-math]

I'd like to propose changing the type signature of FunctionField from

FunctionField{T <: FieldElement}

to

FunctionField{T <: FieldElement, U <: PolyRingElem{T}}

mirroring the existing two-parameter design of RationalFunctionField{T, U}. This is a semi-breaking change, so I want to gauge interest before drafting a PR.

Motivation

Several fields of the FunctionField struct are currently typed existentially or abstractly, because the polynomial ring type U is not carried in the type signature, for example:

• num::Poly{<:PolyRingElem{T}} — existential; concretely stored as Poly{U} for some U <: PolyRingElem{T}, but U does not appear in the struct's type parameters.
• den::PolyRingElem{T} — PolyRingElem is abstract.

Or even

pol::Poly{RationalFunctionFieldElem{T, U}} where U <: PolyRingElem{T}
base_ring::RationalFunctionField{T, U} where U <: PolyRingElem{T}

essentially document that U ought to be a type parameter: RationalFunctionField already takes it, but FunctionField discards it.

Adding U as a second parameter would:

1. Make every field of FunctionField concretely typed, improving type stability and codegen for downstream code.
2. Bring FunctionField in line with RationalFunctionField{T, U}, removing an asymmetry between two closely related types.
3. Eliminate the where U <: PolyRingElem{T} existentials currently needed in field declarations and method signatures.

Cost

I did a quick survey of downstream packages:

• Hecke.jl: roughly 100 references would need updating.
• Oscar.jl: a handful of references.

Further, FunctionField{T, U} would still allow FunctionField{T} usage most of the time, so this should not break the "usual" code.

Should I? Happy to prepare the PR for AbstractAlgebra and the corresponding follow-ups in Hecke and Oscar if this is welcome.

[lgoettgens]

Since this is mostly about Hecke, does @thofma have an opinion on this?

[thofma]

Good idea. No objection on my side.

[fingolfin]

Sounds good to me as well :-)

[alexey-orlov-math]

#2414

I have prepped Hecke side changes too, and the diff is surprisingly small even with "eager" fixes for types.
Also can confirm that removing type assertions in getters in src/generic/FunctionField.jl still keep all "@inferred" tests working and also fixes newly found type instability with defining_polynomial usage in prime_decomposition for function fields over Q(x) (hitting it was the last strain to force me to do this 8))

Hecke.jl: roughly 100 references would need updating.

there are roughly 100 references but only handful were fully typed (in need of an update)

Oscar.jl: a handful of references.

no updates are needed. The usage in src/NumberTheory/GaloisGrp/Qt.jl is safe: since FunctionField U has a U <: PolyRingElem{T} restriction, QQPolyRingElem is the only option so everything should continue to work