You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a language with elaborate (non-s-expression) syntax it is unavoidable that some surface syntax forms won't be able to express everything the underlying object model can represent. And I don't think we can or should allow parsing function = 1.
One thing we could do is fix the printing of NamedTuple{(:function,)}((1,)) to use that syntax rather than (function = 1,).
I wonder if some of @c42f's work on expression parsing and such would facilitate the requested change in printing here (i.e. printing the long-form NamedTuple instead of (function = 1,))
@quinnj I assume you refer to #32408? With the current syntax from that PR I think we could have (var"function" = 1,) in principle and that would be quite a general way of distinguishing between identifiers and keywords.
I think this would require additional changes to the parser in addition to #32408 and the pretty printer would definitely need more work. But it's a neat connection.
Followup to #26507.
This works:
However, direct construction does not work.
There are also (at least) two different failure modes for different reserved words.
Would it be mad to allow this? Alternatively, could it give a uniform and more specific error about bad use of reserved word in named tuple?
The text was updated successfully, but these errors were encountered: