Kind of crucial part of #35362.

I don't really get this. How is this related to #35362. Why does this have to go in 1.5?

Version 1.5 will stop warning for these guys (which I think were actually deprecated in 0.7). That'll make it seem like they're now fine behaviors — even though we had long ago agreed to deprecate them.

That'll make it seem like they're now fine behaviors.

Yeah, that will be the case for all deprecations. So you need to run with deprecations warnings on before you update to a breaking release. So I don't see how the linked PR has any relevance. It was just a policy choice of what to show by default.

Again, I don't see how the linked PR influences this and why it is on the milestone.

Julia 1.4:

julia> filter((k, v) -> isodd(v), Dict(:foo => 1, :bar => 2))
┌ Warning: In `filter(f, dict)`, `f` is now passed a single pair instead of two arguments.
│   caller = top-level scope at REPL[5]:1
└ @ Core REPL[5]:1
Dict{Symbol,Int64} with 1 entry:
  :foo => 1

julia> cmd = `echo "wtf" > test1.log`
┌ Warning: Parsing command "echo "wtf" > test1.log". Special characters "#{}()[]<>|&*?~;" should now be quoted in commands
│   caller = shell_parse(::String, ::Bool; special::String) at shell.jl:107
└ @ Base ./shell.jl:107
`echo wtf '>' test1.log`

Julia master since #35362:

julia> filter((k, v) -> isodd(v), Dict(:foo => 1, :bar => 2))
Dict{Symbol,Int64} with 1 entry:
  :foo => 1

julia> cmd = `echo "wtf" > test1.log`
`echo wtf '>' test1.log`

Since those both work with no warning on master, if we released 1.5 as is, we would be required to keep these "features" for the rest of the 1.x series. That is NOT what we want: we want to make the filter an error and we want to make the backtick expresison construct a pipeline that writes to a file. Releasing 1.5 would make both of those changes semver violations.

This PR makes them hard errors:

julia> filter((k, v) -> isodd(v), Dict(:foo => 1, :bar => 2))
ERROR: MethodError: no method matching (::var"#1#2")(::Pair{Symbol,Int64})
Closest candidates are:
  #1(::Any, ::Any) at REPL[1]:1
Stacktrace:
 [1] filter(::var"#1#2", ::Dict{Symbol,Int64}) at ./abstractdict.jl:428
 [2] top-level scope at REPL[1]:1

julia> cmd = `echo "wtf" > test1.log`
ERROR: LoadError: parsing command `echo "wtf" > test1.log`: special characters "#{}()[]<>|&*?~;" must be quoted in commands
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] shell_parse(::String, ::Bool; special::String) at ./shell.jl:100
 [3] @cmd(::LineNumberNode, ::Module, ::Any) at ./cmd.jl:389
in expression starting at REPL[2]:1

We can break code that worked in a previous version but emitted a warning by default. We cannot break code that worked without any warning by default. If 1.5 goes out with these constructs working with no warning, then we'll be stuck with them. That's the problem.

FWIW, I put it on the milestone not because I want to single-handedly force this into Julia 1.5, but rather that we absolutely must decide one way or another before we feature freeze.

There's also some previously squeaky deprecations in base/deprecated.jl that are now silent. We should either make the squeaky again or make them errors. There are also some notes in there about deprecating things in the future, which we should maybe go ahead and turn into deprecations now that deprecations are silent by default.

keep these "features" for the rest of the 1.x series

I think, technically, this is actually what we have to do to make it completely SemVer compliment.

See SemVer FAQ

When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

I think the bold part (by me) implies that removing a feature should always be done by a major bump. I think this is true even when the deprecation warnings were enabled in the previous "major" version (= 0.7). Of course, we always have the escape hatch ("minor change")...

Perhaps the least breaking action is to create a "hard" depwarn that cannot be suppressed by --depwarn=no. It may annoy more people, though.

These have been deprecated since 0.7.0 so we are complying with semver. In any case, if people have been ignoring warnings since 0.7, I'm ok with breaking their code regardless of the letter of the law here.

We can break code that worked in a previous version but emitted a warning by default. We cannot break code that worked without any warning by default.

This doesn't make sense to me (I don't see how the "default" printing of deprecation warning is relevant). This code has been deprecated since 0.7 and is still deprecated? Yes, you now need to run with --depwarn=yes to see it but that is documented. The exact implementation of a deprecation system is not really mentioned by e.g. semver afaiu.