Skip to content

Conversation

@JamesWrigley
Copy link
Member

As discussed in JuliaLang/JuliaSyntax.jl#600 and JuliaLang/JuliaSyntax.jl#615. Tested manually on 1.12. Should finally for-realsies fix JuliaLang/JuliaSyntax.jl#600 🤞

Copy link
Member

@c42f c42f left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks!

is_paren_call=is_paren_call,
is_block=!is_paren_call && num_semis > 0)
end
end::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly neater?

Suggested change
end::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}
end
opts::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually didn't realize that was possible 👀 Does a type-assert after the variable initialization have the same effect? I think I have a mild preference for the current version because that's clearer to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type-inference knows that opts is constrained by the type-assert everywhere "downstream" of this, so this should be effectively the same in practice yeah

(no opinion from me w.r.t. style)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup what Cody said. To expand: type inference follows the data flow according to program control flow. Unlike in some languages, the type assert opts::T is not a global statement about the binding opts. It just asserts the type of the value bound to opts is T at that one point in the program and inference can follow the program dataflow from there.

Style-wise I think it makes slight sense to separate performance annotations from the rest of the code as they're not semantically relevant for humans reading the code. But that's nitpicking, I think this is fine and we can just merge it :)

@JamesWrigley JamesWrigley added backport 1.12 Change should be backported to release-1.12 backport 1.13 labels Jan 4, 2026
@c42f c42f merged commit 05c973a into JuliaLang:master Jan 5, 2026
11 checks passed
@JamesWrigley JamesWrigley deleted the parse-brackets-typeassert branch January 5, 2026 09:50
JamesWrigley added a commit to JamesWrigley/JuliaSyntax.jl that referenced this pull request Jan 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport 1.12 Change should be backported to release-1.12 backport 1.13

Projects

None yet

Development

Successfully merging this pull request may close these issues.

parse_brackets should probably specialize on the function

4 participants