Closed mhauru closed 1 month ago
For context, here are the method ambiguities: https://github.com/TuringLang/Turing.jl/actions/runs/10161073643/job/28098796083?pr=2290#step:8:305
They arise from three functions:
tilde_assume
; this should have been fixed in https://github.com/TuringLang/DynamicPPL.jl/pull/636 and https://github.com/TuringLang/Turing.jl/pull/2299
bundle_samples
; these are fixed in https://github.com/TuringLang/Turing.jl/pull/2304
get
:
I ran the optimisation test suite (julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim
) and this method is only ever called with either Tuple{Symbol}
or Vector{Symbol}
.
Restricting the second argument to these would make sense as a fix for the method ambiguity, and in all likelihood would capture reasonable use cases, but would technically be a breaking change.
Would it help if we defined something like
function Base.get(m::ModeResult, var_symbols::AbstactLens)
? Not sure what the method should do. I guess it could call get(m, tuple(var_symbols...))
in case some lens type is iterable, or alternatively just error straight away.
Having mulled it over a bit, I think my preferred option would just be to swallow the breaking change and bump the minor version, as otherwise we will end up playing whack-a-mole with any other dependencies that might choose to define Base.get(x, y::WhateverType)
.
If we think it's too trivial to release 0.34 over this, we could wait until there are other breaking changes to be made and then bundle them in together. (Most mature packages do that anyway.) And use github milestones ;)
In #2257 I disabled method ambiguity checking, but @devmotion suggested enabling them with
We should do that and see if we can fix the 6 ambiguities that it warns about. I'm happy to do this, but off next week, so will take a moment.