Allow typevars in do
expressions
#437
Open
+4
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are several ways to create functions in julia. One of them is the
do
syntax. You can't dispatch ondo
functions, but now and then the need comes up to capture the types of variables. Although this is easy withtypeof
inside the function body, it turns out to be quite easy to enable the use ofwhere
clauses in thedo
syntax. This would make ado
function similar to the other function definitions.The reason it's easy is that such expressions are already being parsed, but a minor detail prevents it from being accepted as a valid expression:
The
where
clause becomes encapsulated in atuple
. The reason is that after the parser seesdo
, it looks for a comma separated list. After the list is parsed, i.e. on;
or linefeed, the list is encapsulated in atuple
. This means that thewhere
clause becomes an argument to the function, which fails as a syntax error. By modifying the parsing ofdo
expressions to avoid insertingtuple
if the newly parsed list is awhere
, the parse result becomes:This is a valid
:->
expression, just like an anonymous function definition((x::T) where T) -> T(x)
currently is.The PR is a one-line change to
parser.jl
, isolated to parsing what followsdo
. It does not enable any new or very useful functionality, it merely will make functions defined indo
quite similar to other function definitions.I don't think this change will break anything, as the construction currently results in a
ERROR: syntax: ...
failure.