PSA: Parametric method syntax deprecation about to drop

Just a heads up. In my estimation, this could very well be the single biggest source of deprecation warnings ever, and that’s saying something. If anyone has any final thoughts, now is the time.


See✓&q="where+syntax"&type=Commits for what transitioning Base over to the new syntax has looked like over the past several months.

1 Like

Yeah, this is going to be a bit painful. Apologies in advance, for not having a better syntax for this in the first place and thereby inflicting this on everyone. I posted over here about the motivation for the change:

I wonder whether a script could be written using Tokenize.jl and/or CSTParser.jl to try to automatically switch these over. Would probably be more complicated than the one for the type keywords from

Yes, I know CSTParser (@zacln) used to have a deprecation warning for that so at least CSTParser can detect it. Maaaybe writing a small script to do the transformation wouldnt be so hard.

The julia-vscode plugin detects this and has an automatic fix (click on hint region then on the lightbulb that pops up) for either single instances, or all within a file.


I think you’re going to get a lot of new users because of that feature :slight_smile: .

That is really amazing. Just clicking “like” on that post is not enough :slight_smile: I will now finally have to try vscode!

Just tried it. Awesome! I’ve been using VS Code a while, but I missed this. I’ll have to watch the release notes from David and Zac more carefully.

Would it be possible to extract that functionality into a standalone script to fix up Julia source files?


Just to be clear, this is “about to drop” in 0.7-master, not a 0.6 feature?


1 Like

Yes. We could also make a GitHub bot or integration of some sort.


As Jeff said, yes, on 0.7-DEV – there will be no new features or breaking changes on 0.6.


fixdep(filename, overwrite = false)

EDIT: though without the full namespace scoping it can’t distinguish between function calls and type constructors


I’m not convinced of this idea myself, but I thought I’d throw it out there.

To ease this exceptional deprecatastrophe, perhaps it would make sense to have a special 0.6.1 release halfway through the 0.6 life-cycle in which the only change is this deprecation. This might make the transition easier on people since it won’t be accompanied by lots of other deprecations and errors. The alternative thinking is that it is better to resolve deprecations all at once, but in practice I’ve noticed that it sometimes takes them a long time to get fixed, so perhaps a staged approach is better.

I think that 0.7 is largely serving that purpose by providing a smoother deprecation path to 1.0.

1 Like

I don’t think that making people update deprecations more times is helpful. It’s not all that hard to do, it’s just kind of annoying, so doing it fewer times is generally better.

Here is a bit of an extension to the fixer by @ZacLN. It patches all the julia files in a package on a checked out branch, and makes a commit with the changes. Blam, ready for PR. I just did with it.

function fixpkg(pkg::String, overwrite = false)
    !isdir(Pkg.dir(pkg)) && error("Did not find package directory")
    repo = LibGit2.GitRepo(Pkg.dir(pkg))    
    LibGit2.isdirty(repo) && error("Package repo is dirty")
    if overwrite
        info("Checking out branch fix_where")
        LibGit2.branch!(repo, "fix_where")
    for (root, dirs, files) in walkdir(Pkg.dir(pkg))
        for file in files
            if endswith(file, ".jl")
                FixParameterisedFunctionDeprecation.fixdep(joinpath(root, file), overwrite)
                if overwrite
                    LibGit2.add!(repo, joinpath(root, split(root, Pkg.dir(pkg))[2]))
    overwrite && LibGit2.commit(repo, "fix deprecation warnings for new where syntax")

Is it possible to be consistent with the spaces, i.e. I would like it to remove spaces? E.g. f{T<:Float32}(x::T) = T(2.0) gets transformed to f(x::T) where {T <: Float32} = x instead of f(x::T) where {T<:Float32} = x