Allow type variables with `do` syntax

[PatrickHaecker]

The do syntax should support type variables, so that something like

myfunction(bound_parameter) do free_parameter::T where T
    # T should be available here
end

or at least

myfunction(bound_parameter) do (free_parameter::T) where T
    # T should be available here
end

should behave the same as in regular functions regarding T .

There are three reasons why the do syntax should allow type variables:

• To support multiple dispatch in case of multiple method definitions
• To support cases where the type is used statically
• For consistency reasons: Ideally each way of defining functions should support all functionality

This is discussed in a Question and a Suggestion. A change proposal is already provided by sgaure (without pull request).

[nsajko]

IMO an issue on an issue tracker should be self-contained. It's OK to link to various previous discussions for context, but you can't expect anyone to click on the provided links to get at the actual meat of the matter.

[sgaure]

I did make a PR to JuliaSyntax. It's a one-liner.

JuliaLang/JuliaSyntax.jl#437

[PatrickHaecker]

IMO an issue on an issue tracker should be self-contained.

Thanks for the hint. I expected to have the most relevant information in the heading and the first sentence, but I agree that this was very terse. I hope it's now more clear with the explicit syntax proposal.

[JeffBezanson]

If this doesn't cause any problems in the parser, looks like an obvious win to me.

[c42f]

Which version is this proposal suggesting?

Requiring the parens seems problematic, because do with parens currently means argument destructuring:

julia> g(f, args...) = f(args...)
g (generic function with 1 method)

julia> g([1,2]) do (x, y)
           @info "Look, they're unpacked" x y
       end
┌ Info: Look, they're unpacked
│   x = 1
└   y = 2

It would not be good if the parentheses mean something different when the where was added.

[c42f]

The fact that argument destructuring is supported in this case is arguably quite confusing and the best long term solution may be to make parentheses irrelevant in do argument lists?

For example here's a very prolific and experienced Julia user getting confused by this: #47661

[c42f]

Making progress toward deprecating destructuring for this case would be a long term prospect I suspect. We could assess the current state by looking at how many times it occurs in the package ecosystem.

[MasonProtter]

The fact that argument destructuring is supported in this case is arguably quite confusing and the best long term solution may be to make parentheses irrelevant in do argument lists?

IMO that's not viable. People write things like

map(Iterators.product(a, b)) do (x, y)
    #...
end

all the time.

[StefanKarpinski]

The syntax I would consider reasonable here would be:

f(a, b) do x::T, y::T where T
    # body
end

I'm not sure why you'd need to do this though...

[JeffBezanson]

Yeah I agree the way parens work here was probably a mistake; f() do x, y and f() do (x, y) should have been the same, both 2-argument functions, with f() do ((x,y),) for destructuring. As it is I'm not sure we can do anything about this.

[c42f]

We can possibly have the syntax @StefanKarpinski suggested - my guess would be that this is not used in practice for simple reasons of obscurity. However, it's technically breaking and we'd need to guess at whether it's actually breaking based on usage in General :-/

Another option could be to finally do #32071 and make this the only supported way to express where and do together, for now. It's not great, but it might do?

In either of these cases, I'd favor a long-term plan to make the current do+destructuring syntax a warning and eventually change it in "the mythical Julia 2.0". I like that syntax-appreciators like @MasonProtter like it and do understand it perfectly well! But it seems high on confusion and low on utility for the average user.

[jariji]

I'm concerned that a syntax warning wouldn't be actionable because all do ... syntax already has a meaning. For example, in

julia> map(Iterators.product(1:2, 10:10:20)) do (x, y)
           x,y
       end
2×2 Matrix{Tuple{Int64, Int64}}:
 (1, 10)  (1, 20)
 (2, 10)  (2, 20)

SYNTAX WARNING: Destructuring syntax will change. For this use `do ((x,y),)`.

The user is instructed to use do ((x,y),). But the user can't do that, because do ((x,y),) already means destructuring yet another level:

julia> map(Iterators.product(1:2, 10:10:20)) do ((x, y),)
           x,y
       end
ERROR: BoundsError: attempt to access Int64 at index [2]

[c42f]

all do ... syntax already has a meaning

Good point. To make any progress on syntax issues like this and others, we probably need to adopt something like Rust Editions which allow module-local breaking syntax changes. They allow carefully considered breaking changes without bifurcating the ecosystem:

When creating editions, there is one most consequential rule: crates in one edition must seamlessly interoperate with those compiled with other editions.

JuliaSyntax already has a system for version-aware parsing. The main thing would be to add the edition to Project.toml (presumably) and we could do something like this on an opt-in basis.