deprecate &x syntax in ccall, replace with Ref

[pygy]

|(::String) = 4
# | (generic function with 49 methods)

&(::String) = 6
# ERROR: syntax: invalid identifier name "::"

|(123,456)
#507

&(123,456)
# ERROR: unsupported or misplaced expression &

Base.(:&) works as intended.

[StefanKarpinski]

You need to put parens around some operators to use them in prefix form. I forget why this is, but it is the case for some operators and it's not a bug.

[pygy]

It's surprising that only some of them work without the parens. If it's not a bug, so be it.

I'm curious about the reason, though.

[StefanKarpinski]

It's because & as a unary operator is a special syntax that has meaning for ccall arguments. Since that's a very niche situation, however, I wonder if we couldn't allow prefix usage of the & function elsewhere.

[pygy]

You could mandate the parentheses for prefix & calls in ccall expressions, but not everywhere else.

The ccall section of the manual already documents special & syntax in that contex, a remark about prefix & calls could be appended to that paragraph.

[JeffBezanson]

Now that an alternative is available, we need to decide whether to fully deprecate & syntax in ccall.

[tkelman]

There's still a performance cost to using Ref in ccall right? Guess that needs fixing before & in ccall can be deprecated without performance regressions.

[StefanKarpinski]

There was a change to use Ref in the LAPACK wrappers and it was way too slow. I believe that performance issue is the blocker from completely removing the use of & in ccall.

[JeffBezanson]

#11402

[vtjnash]

need to deprecate & in ccall first, which is probably mostly pending #18632 right now (although that's not required for making this efficient – only need the easy case of #8134)

[JeffBezanson]

#22684 and #22734 will enable this.

[yuyichao]

Ah, so here's the issue..... Somehow I couldn't find this when openning the two prs....

[musm]

#22684 has been merged 👍 so the only thing left here is to update base definitions that use & and add a deprecation ?

[StefanKarpinski]

Yeah, I think so. There was a PR for this, but it may be easier to just do it from scratch. Do you want to tackle this, @musm? If so, that would be great.

[musm]

@StefanKarpinski I am working on this

[JeffBezanson]

Deprecation is in for 0.7. For 1.0, we should change the parsing of &x to a call expression.