deprecate zero-arg Matrix constructors (#14201)

[StefanKarpinski]

No description provided.

[JeffBezanson]

Need to pick between this and #20250. I vote for deprecating the zero-arg constructors; Matrix() does not seem very meaningful to me.

[tkelman]

why is this removed? still seems valid to me

[StefanKarpinski]

accident

[tkelman]

it's not a good idea to test depwarns like this, --depwarn=error doesn't always apply, for example if running with JULIA_CPU_CORES=1

[StefanKarpinski]

Then how do you recommend doing it?

[tkelman]

probably leave it out for now unless we want to add a depwarn_exec.jl file that we run in a separate process with known --depwarn settings.

if JULIA_CPU_CORES=1 make test-arrayops passes on this branch then this might be fine

[StefanKarpinski]

We could have a @test_deprecated macro that does this for you. Usage would be something like this:

@test_deprecated size(Matrix{Int}()) == (0,0)

which would expand to one of the following, depending on the value of Base.JLOptions().depwarn:

@test_throws ErrorException size(Matrix{Int}())
@test_warn "deprecated" size(Matrix{Int}())
@test size(Matrix{Int}()) == (0,0)

The main reason I wanted this complexity in here is so that I couldn't possibly forget to update the tests when we delete the deprecations for 1.0.

[tkelman]

that's a very good idea

[tkelman]

though we probably want to put such tests in a single place and make sure they get run regularly with all 3 values of the flag (or expand to 3 tests that modify the option in a scoped way, if that's possible inside julia)

[stevengj]

I would prefer to deprecate Vector() as well.

[StefanKarpinski]

I would too but I have a suspicion it's fairly widely used, so I wanted to do the uncontroversial part first. It's fairly common to initialize a vector with zero elements and there was a period where [] created a Void eltype empty array. There's also a consistency argument here: if we deprecate that we should also deprecate Vector{T}() – are you in favor of that as well?

[stevengj]

Yes.

[stevengj]

I grepped for Vector() or Vector{Foo}() in all registered packages, and you're right that quite a few packages use it:

ASTInterpreter,AWS,AbstractTables,ApproxFun,Bio,BlackBoxOptim,Bukdu,CBOR,Clipper,Clustering,Compat,ControlCore,ControlSystems,Cxx,DSGE,DWARF,DataCubes,DataFrames,DeterministicPolicyGradient,DifferentialDynamicProgramming,Diversity,Dopri,EMIRT,GUITestRunner,Gallium,Graft,Hecke,IntervalWavelets,Isotonic,JuliaFEM,LLVM,LightGraphs,LightGraphsExtras,Lumberjack,Mamba,MetadataTools,Metamath,MultidimensionalTables,MultipleTesting,NearestNeighbors,NetworkFlows,NullableArrays,ODBC,ODEInterface,ObjFileBase,OpenDSSDirect,ParallelAccelerator,ParserCombinator,PlotRecipes,PlyIO,Primes,QuantumLab,RData,ResettableStacks,RigidBodyDynamics,RouletteWheels,SALSA,SemidefiniteModel,SemidefiniteModels,StaticArrays,StructuredQueries,SugarBLAS,Sundials,TensorDecompositions,TerminalUI,TestRunner,ThermodynamicsTable,TimeSeries,TimeSeriesIO,TravelingSalesmanHeuristics,Turing,TypedTables,Voronoi,WiltonInts84,WordNet

[stevengj]

A much smaller number of packages use Matrix() or Matrix{T}():

Bio,DSGE,DifferentialDynamicProgramming,Elemental,JPLEphemeris,JuliaFEM,LightGraphs,Mamba,NearestNeighbors,OpenDSSDirect,ParallelAccelerator

[martinholters]

I'd also favor deprecating Vector() and Vector{T}(), but doing so in a separate PR due to the expected controversy sounds like a good idea.

[yurivish]

Now that we have femtocleaner would this be a less controversial change?

[fredrikekre]

See #22717