Sanitize the ternary operator and question mark parsing situation (deprecations only) #22712
Conversation
ararslan
added
the
kind:deprecation
|
💯 to this!! I don't have the Scheme chops to review the actual implementation of the changes but I fully approve of the the approach you describe. It seems fine to me for a language's parser (as opposed to a linter) to enforce readable code in cases such as this, when it disambiguates meaning. It also seems like it will make the introduction of Regarding further deprecations, I would also love to see spaces around the colon in range expressions deprecated. That would complement the changes here quite well, in my opinion. |
|
Note: the current CI failures are unrelated. 32-bit Linux timed out and Windows failed due to existing libgit2 issues. |
|
Spaces around the colon in ranges are useful when start, end, or step are calculated from some nontrivial expression rather than a literal or short variable name. |
|
@tkelman I've found that parentheses are generally equally adequate |
carlobaldassi
force-pushed
the
cb/ternary_spaces
branch
from
110fe82
to
10d41a7
Compare
* deprecate no space after the ? (no space before was already deprecated) * deprecate no space around the : * fix instances where no spaces were used in Base
carlobaldassi
force-pushed
the
cb/ternary_spaces
branch
from
10d41a7
to
fabe9ee
Compare
|
should probably adjust the NEWS bullet from #22619 |
|
Rebased and updated NEWS and docs. (There is also an unrelated small fix in the NEWS that I happened to catch.) It seems nobody is against this and that it could be merged. @JeffBezanson do the parser changes look ok? |
carlobaldassi
changed the title
src/julia-parser.scm
Outdated
| (begin0 (ts:last-tok s) | ||
| (ts:set-tok! s #f))))) | ||
| (if (and (not allow-question-mark) (eq? t '?)) | ||
| (syntax-deprecation s "`?` used as an identifier" "")) |
There was a problem hiding this comment.
This should be part of the function check-identifier. See if that works. If it does, we might be able to get rid of allow-question-mark as well.
There was a problem hiding this comment.
Ah thanks, I don't know how I missed that. It seems to work fine, I have updated the PR.
carlobaldassi
force-pushed
the
cb/ternary_spaces
branch
from
e4cebea
to
2555ec2
Compare
|
Addressed review comments, tests pass. |
|
I manually squashed the related commits and merged into master. It won't recognize the PR as merged, so closing. Oh well. |
These are 2, mostly independent, commits:
The first is about requiring spaces around ternary operators tokens, both the
?and the:. Omitting a space in front of the?was just deprecated in e91c0ff, which was done in view of allowing expressions likeT?in the future. The extension in this PR is not required for that, but in my opinion it helps a lot in disambiguating visually at first glance the uses of ternary operators vs the other meanings of?/:(in particular, ranges).For example, this deprecation caught the following line in Base:
(size(M, t=='N' ? 1:2), size(M, t=='N' ? 2:1)). To me, it seems unnecessarily difficult to see that1:2and2:1are not ranges. By the way, in the same spirit it may be desirable to deprecate writing ranges with spaces, e.g.1 :2. If we had these rules, distinguishing the use of colon in ternary operators, ranges and symbols would be much much easier. The set of parsing rules for?and:would be purely local, rather than context-dependent, and easy to explain and understand.I expect that a major objection to such change is that this should be the job for a linter, not a parser. On the other hand, I really don't see the benefit in allowing a style which to me nearly amounts at code obfuscation, while the "cost" of this change is negligible.
(There is also an argument of symmetry, since the fact that a space is required before
?but not after simply irks me, but then again it's just me probably.)The second commit, I would assume, is less controversial, at least in its intent if not in the implementation: it deprecates the use of
?as an identifier. This is possible right now purely by accident (it "slips through" the parser rules), and it has long been recognized as undesirable. See issue ? behaves strangely as an identifier #6286, in particular this comment. See also issue Should?not be allowed as an identifier name? #19061 for some examples of the silliness which can arise by allowing it. Another major problem IMO in allowing an identifier or expression to start with?is that it can not be easily entered in the REPL, as it clashes with the help mode. Of course, this deprecation would not disallow the possibility to parseT?, or even use?as part of an identifier name, provided it is not the first character.As far as I'm aware, right now
?is only used in this way by the Nulls.jl package, as a placeholder until theT?syntax is available (Please don't use ? as a unary operator? JuliaData/Missings.jl#17). I guess that they could either live with the deprecation until then, or just use any other symbol among the bazillions that are available, e.g. ❓ (\:question:) or⍰(\APLboxquestion) (cc @ararslan).