things we should deprecate, 0.6 edition

[StefanKarpinski]

I'd like to collect a list of things that should be deprecated before 0.6 is released, even if we don't implement the corresponding feature until 1.0. Some examples I can think of:

• Strings: "hello".data access – we need to change the representation of strings to make them more efficient, which is almost certainly not going to allow accessing their underlying bytes like this. So we need to deprecate this and provide an alternative API for this sort of thing. faster String allocation #19449.

• Backtick syntax: deprecate using shell-special characters inside of backtick command syntax. At this point we can write most shell constructs in Julia, but it's gotten a bit more verbose and inconvenient than I'd like. So, in 1.0 I'd like to make, e.g. `echo hello & echo world | sort >> file.txt` construct a pipeline that runs two echo commands in parallel and connects them to the stdin of a sort command and then connects the output of sort to the file file.txt opened in append mode. deprecate unescaped shell special chars in commands #19786

• the elementwise meaning of | and & given we're about to have .| and .& Deprecate manually vectorized methods in favor of dot syntax, monolithic edition #19791

• depreaction of sumabs, sumabs2, maxabs and minabs which are not necessary with fast function arguments. Deprecate sumabs, sumabs2, minabs, maxabs #19616

• Array(T, dims...) (RFC: Deprecate Array(T, dims...) #19989)

• partial linear indexing, done in RFC: Deprecate partial linear indexing #20079

• produce/consume (issue Deprecate produce-consume #17699)

• vectorized isinteger, et al. (deprecate array-reducing isinteger #19925)

• vectorized frexp (Deprecate frexp{T<:AbstractFloat}(A::Array{T}) in favor of broadcast ? #19817)

• promote_eltype_op (Remove broadcast_elwise_op and deprecate promote_eltype_op #19814)

• deprecate vectorized ifelse in favor of dot syntax (Deprecate vectorized ifelse in favor of dot syntax #19931)

• deprecate _ as a rvalue (Dummy variable _ #9343, deprecate using _ as an rvalue #20328)

• ~ macro syntax the overall plan from things we should deprecate, 0.6 edition #19598 (comment):

  • change the one user of this as a macro – i.e. StatsModels (WIP: Replace infix ~ for formulas with a model macro JuliaStats/StatsModels.jl#9)

  • update DataFrames to depend on the new version of StatsModels (issue/PR link?)

  • change parsing of ~ in Base from macro to plain infix operator

• Open for read and write: we need to get rid of readandwrite so whatever deprecation we need to make there should be made. This may be harder since we may need to implement the change. Change open(cmd) to return Process instead of Tuple #12807

• Inner constructor syntax, see things we should deprecate, 0.6 edition #19598 (comment)

• Static parameter syntax, see things we should deprecate, 0.6 edition #19598 (comment)

• Deprecate reducer form of @parallel: RFC: "for-loop" compliant @parallel for.... take 2 #20259, waiting for a review

Probably in 1.0 rather than 0.6:

• Various special functions, pending Special functions to Base #4301/move special functions out of Base? #8536

• full – @Sacha0, how are we on this?

[tkelman]

• the elementwise meaning of | and & given we're about to have .| and .&
  edit: done in Deprecate manually vectorized methods in favor of dot syntax, monolithic edition #19791 – @StefanKarpinski
• macro parsing of ~ if the stats packages can come up with a @formula replacement in time

[nalimilan]

macro parsing of ~ if the stats package can come up with a @formula replacement in time

Should probably go into StatsModels now.

[ararslan]

Regarding formulas, see JuliaStats/StatsModels.jl#3.

[Sacha0]

Alongside @tkelman's mention of vectorized & and |, remaining vectorized methods for abs, abs2, imag, trunc, floor, ceil, mod, div, rem, clamp, and a number of hyperbolic trig functions should be deprecated. Likely vectorized big methods as well, and possibly (discussion ongoing) vectorized float, real, and (two-argument) complex methods. (I have stale pull requests open for most of those deprecations, blocked on whatever mark we set for completion of the sparse broadcast overhaul.) (edit: These are done, less those struck through.)

With devectorization complete, deprecation of expm, logm, sqrtm, and friends (i.e. matrix functions specially named due to former conflict with vectorized scalar functions) in favor of non-m equivalents might be worth considering. Best!

Edit: Also full. (I hope to see deprecating full through after completing the sparse map/broadcast overhaul (post 0.6).)

[andreasnoack]

I'd also propose depreaction of sumabs, sumabs2, maxabs and minabs which are not necessary with fast function arguments.

Edit: done in #19616 – @StefanKarpinski

[simonbyrne]

Various special functions, pending #4301/#8536

[simonbyrne]

For strings, the decision was to define a codeunit(s::String, offset::Int) function for people who need access to bytes.

[StefanKarpinski]

If Jeff's recent String experiment pans out, we'll do that; otherwise we rename the .data field.

[tkelman]

• partial indexing deprecate (then remove) generalized linear indexing #14770, but maybe too big of a job to fit before 0.6 feature freeze

• vectorized isinteger (and maybe others) on arrays, replace with all(isinteger, x) (edit: isinteger done - @Sacha0)

[vtjnash]

If Jeff's recent String experiment pans out, we'll do that; otherwise we rename the .data field.

I think we said that Jeff's recent String experiment is expected to merge in the next few months, otherwise we don't spend any other effort on changing the representation. Probably by 1.0, we will need to have the infrastructure in place to handle Arrays more efficiently via an underlying Buffer type. At that time, we can delete the special case code for String and go back to having a .data field, by showing that it gives the same (or better) performance.

[JeffBezanson]

Another candidate: produce and consume, in favor of channels.