need mechanism to deprecate bindings

[timholy]

While we can deprecate functions, our current mechanism to deprecate types is to define the equivalent of

export Range1
const Range1 = UnitRange

This does not trigger any deprecation warning for using the type itself. #11046 was therefore more disruptive than one might have ideally wished (see JuliaGraphics/Tk.jl#98 and cascading breakages in any package that depends on it, plus at least timholy/ProfileView.jl#32), in that it caused actual package breakages. If we'd had a deprecation system in place, the appropriate changes could have been made any time in the past year.

I presume this is something that needs to be handled at the parser level?

(Off-topic: should we have a "wishlist" label as distinct from bug reports?)

[jakebolewski]

You can't really do this at the parser level because it is perfectly valid to use the name of a Type as a local variable.

julia> type MyType
       x::Int
       end

julia> let MyType = 1
       @show MyType
       end
MyType = 1
1

julia> MyType(10)
MyType(10)

[timholy]

Good point. Thanks for taking that label off.

[jakebolewski]

But I agree this is big problem that will trigger all sorts of compatibility issues going forward.

It makes it impossible to implement improvements such as #8240 because the result will be backwards incompatible with no clear deprecation path.

[StefanKarpinski]

This has come up before, what's really needed it seems, is to have a deprecated export mechanism, where a name can be made available, but using it triggers a warning in the other module.

[StefanKarpinski]

That distinction would be more broadly useful: e.g. if two module both export names but one of the exports is deprecated, maybe the non-deprecated name should win? It would also be nice not to tab complete deprecated names and methods.

[ScottPJones]

👍 @StefanKarpinski Any how hard to implement deprecated export mechanism, allowing non-deprecated name to win, and no tab completion?

[StefanKarpinski]

It would be a fair amount of work that not very many people could do.

[ScottPJones]

@StefanKarpinski Be careful about making challenges like that! 😀

[StefanKarpinski]

Well, I'd be happy for anyone to do it, but it just involves a whole lot of Julia blood and guts.

[ScottPJones]

Julia blood and guts? But, that's the most fun part, for an old language design / compiler guy like me! 😀 Seriously, if you already know approximately what areas would need to be dug into, and could point them out, then that's something else where I might be able to take a crack at it...

[jiahao]

#9830 is a special case of this problem, I think.