Julia: `begin` in indexing expression (possibly inside macro call)

[alyst]

On 1.0.1 and 4-days-old master I get

julia> Int[begin; i; end for i in 1:3]
┌ Warning: Deprecated syntax `"begin" inside indexing expression` at REPL[1]:1.
└ @ REPL[1]:1
3-element Array{Int64,1}:
 1
 2
 3

without explicit eltype it's fine

julia> [begin; i; end for i in 1:3]
3-element Array{Int64,1}:
 1
 2
 3

[yuyichao]

It IS an indexing expression though, and it only is when it's typed so this isn't a false positive.

[alyst]

So it would be deprecated?

[JeffBezanson]

The problem is that when we see Int[begin it initially looks like indexing, and only later turns into a comprehension. This is so we can allow something like A[begin+1]. However, personally I'd like to be able to write begin blocks in comprehensions, so I'm not 100% happy with this solution.

[timholy]

Hmm. We probably should have just changed indexing to use something different than end, e.g., https://github.com/JuliaArrays/EndpointRanges.jl. Worth putting on the agenda for 2.0?

[mschauer]

I am making advertisement for a far future where $begin and $end replace begin and end in indexing contexts: these cannot be macro names, so they are free and do not need a new keyword, they resonate with the idea that the parser substitutes $end with something and they disentangle special indexing and block syntax.

[StefanKarpinski]

FWIW, Jeff and I spent a lot of time trying to brainstorm better syntaxes for this. We didn't come up with anything better than begin and end, although $begin and $end did not occur to us. Too late now for Julia 1.x; would be worth keeping in mind as a potential change for Julia 2.0.

[clarkevans]

In various query contexts, indexing syntax is a rather natural way to express a selector, such as an XPath expression. In this regard, blocks (begin/end) could be very nice inside an indexing expression. Our particular case involves data[@query begin ... end] which is also, sadly, deprecated. This deprecation rules out the use of indexing expressions in combination with blocks. Is the deprecation necessary?

[JeffBezanson]

Seems to me we should be able to allow it inside macro calls. I'll look into it.

[clarkevans]

Seems to me we should be able to allow it inside macro calls. I'll look into it.

Thank you for taking the time to listen and follow up to the list. Should we make this a ticket? Anyway, it'd be great if data[@query begin ... end]might no longer be deprecated. I think it works beautifully, save the warning message. There are workarounds, @query data begin ... end. But it's not as nice.

[JeffBezanson]

So it turns out we allow a[@mac(end)], presumably so the macro can transform it to e.g. a[end-1]. That seems slightly dubious to me. Changing that would be breaking, but if we want to we can start down that path by not extending this behavior to begin. Then we would eventually remove a[@mac(end)] too.

[clarkevans]

@JeffBezanson Is removing the deprecation warning in the macro case (data[@query begin ... end]) a separate topic/issue, or is it tied into this breaking change? I'm busy updating a tutorial... the indexing syntax is just so much cleaner than a 2 argument macro, e.g. @query data begin ... end fallback. The former syntax makes it clear that the query construction is different from applying it to a data source, while the work-around conflates the two disjoint activities. Thank you so, so much for your amazing help.

[JeffBezanson]

It's connected in that allowing a[@x begin end] now means we will need to disallow a[@x(end)] in the future to be consistent --- otherwise begin as an index doesn't work the same as end as an index.

[StefanKarpinski]

Alternative syntaxes for A[begin] and A[end] in the 2.0 timeframe might be A[@begin] and A[@end] or A[$begin] and A[$end].

[c42f]

@end looks reasonable but A[@end - 1] currently parses with the - 1 consumed by the macro call. I guess special case parser support for known zero-arg macros would be needed to fix that.

It's the same problem we currently have with things like @__LINE__ + 1 but more annoying.

[c42f]

Here's a fun example of block syntax within a ref which currently works in version 1 but which would mean something very different if begin referred to the first index:

julia> A = Dict((-) => 1)
Dict{typeof(-),Int64} with 1 entry:
  - => 1

julia> A[begin - end]
┌ Warning: Deprecated syntax `"begin" inside indexing expression` at REPL[17]:1.
└ @ REPL[17]:1
1

Another random idea might be A[begin'] and A[end'] or any other combination of the keywords with prefix or postfix operators. It's a bit arbitrary but somehow easier on the eyes and also easier to type.