-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New syntax deprecation warnings double print output in REPL #8603
Comments
This must be because the REPL somehow ends up parsing the input twice. The deprecation warnings make parsing non-pure. I noticed this, but figured it wasn't so important. You only really need the warnings for files, to see which lines to change. |
This also means that if you have the old syntax inside a multiline expression in the REPL the warning will show. Can we have a mode to the parser that does not print them? |
Just consider yourself really, really warned. There's no need to use the old syntax in the REPL. The old syntax only needs to be supported at all for the sake of loading packages and source files that haven't been updated yet. If anything, it would make sense for the warnings to be syntax errors in the REPL rather than silencing them. |
This isn't unique to these new syntax deprecations. It also has been happening for a long time with older syntax deprecations (such as indexing with missing halves of a range). It's simply because the REPL needs to parse the input to determine if the line is complete or not before actually executing it. julia> zeros(1)[1:]
WARNING: deprecated syntax "x[i:]".
Use "x[i:end]" instead.
julia> zeros(1)[1:]
WARNING: deprecated syntax "x[i:]".
Use "x[i:end]" instead.
1-element Array{Float64,1}:
0.0 |
Speaking of which, I believe that syntax can be fully removed for 0.4. |
"x[i:]" is an error after #8607 |
Not quite the right behavior though, because it raises an error rather than returning an error as other syntax errors do. |
Actually, nevermind I guess syntax errors always abort the REPL multiline input? Not sure I like that behavior. |
They do, which is kind of unfortunate. I would be happier if that were not the case but it's a tricky design. |
I agree that this behavior kind of sucks, but I don't know if it is worth fixing it at the moment. |
The text was updated successfully, but these errors were encountered: