PSA: Parametric method syntax deprecation about to drop

Internals & Design
1

https://github.com/JuliaLang/julia/pull/22834

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.

5 Likes
2

See https://github.com/JuliaLang/julia/search?utf8=✓&q="where+syntax"&type=Commits for what transitioning Base over to the new syntax has looked like over the past several months.

1 Like
3

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:

4

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 https://github.com/JuliaLang/julia/pull/20418#issuecomment-277201589

5

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.

6

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.

19 Likes
7

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

8

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

9

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.

10

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

5 Likes
11

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

12

Yes.

1 Like
13

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

3 Likes
14

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

15

yup, https://gist.github.com/ZacLN/2f0d66c651647e32eae85e58102315cb

fixdep(filename, overwrite = false)

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

3 Likes
16

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.

17

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

1 Like
18

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.

19

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 https://github.com/JuliaStats/Distances.jl/pull/73 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")
    end
    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]))
                end
            end
        end
    end
    overwrite && LibGit2.commit(repo, "fix deprecation warnings for new where syntax")
    return
end
5 Likes
20

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