-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Free up curly brace syntax. #8578
Conversation
105956a
to
09fa3b0
Compare
2ef98c5
to
0388647
Compare
I'm thinking, in Lint, I could add a trigger like "Using {} for Any[] may be deprecated in Julia 0.4" for julia VERSION < v"0.4-". It may help 0.3 users future-proof their code a bit. What do you think? |
+1 to that |
So it is done. |
This is gonna be another one of those "real" 0.4 changes. :) Now we just need a catchy name like the itruncalpyse. |
bracalypse? |
curlpocalypse? |
|
Curler iron. I'll show myself out. |
Brought up to date with latest dictionary syntax changes. @JeffBezanson what are your thoughts on this? I could add a deprecation warning for the time begin for |
For a little while, let's print a deprecation warning but keep it working the same and use |
I wonder if it makes sense to backport some deprecations to the 0.3 branch without breaking any functionality. That way people can have more chance to prepare for some of these bigger changes. |
We would have to make sure that the new functionality actually works
|
Yes, of course. Might not be practical. |
I feel that this would be better handled by external tools rather than cluttering up the parser in Julia. |
Agreed. Some kind of lint tool, or |
ccbc806
to
091ffc1
Compare
Updated with deprecation warnings. |
8dd68da
to
1b6bb8d
Compare
1b6bb8d
to
45bf6be
Compare
Is this good to merge? |
@@ -108,7 +108,7 @@ eval(Sys, :(@deprecate shlib_list dllist)) | |||
@deprecate put put! | |||
@deprecate take take! | |||
|
|||
@deprecate Set(a, b...) Set({a, b...}) | |||
@deprecate Set(a, b...) Set([a, b...]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs Any
to avoid concatenation.
@@ -1812,7 +1818,9 @@ | |||
(length= (cdr x) nc))) | |||
(cddr vex))) | |||
(error "inconsistent shape in cell expression")) | |||
`(cell2d ,nr ,nc | |||
(begin | |||
(syntax-deprecation-warning s "{[a,b] [c,d]}" "Any[[a,b] [c,d]]")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be {a b; c d}
to Any[a b;c d]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should be fixed.
Merge away. |
Free up curly brace syntax.
I can't help but ask (as I've been looking for the answer for a while now), what do you intend to do with curly braces now that they're "free"? |
#8470 is one likely possibility, but suggestions welcome! |
can we get a NEWS.md item for this? I almost missed it, and it's a pretty significant change. also some places in the manual might still need to be updated (http://docs.julialang.org/en/latest/manual/noteworthy-differences/?highlight=matlab and http://docs.julialang.org/en/latest/stdlib/punctuation/?highlight=cell) |
Regarding new uses for brackets, using them for Dict/Hash would align the syntax nicely with Ruby, and move it a step closer to JavaScript/Python/JSON. If they were used for Sets as well, that would match Python. (I'd love to see Julia's Dict literals match the familiar and finger-friendly syntax of Python/JavaScript/JSON, but would guess further use of ':' might be tough to make work well.) |
The fate of the
{}
syntax has been debated in #7941, #7128, #2488, #6739 and many other threads that I cannot dig up at the moment. The current syntax is slated to change in 0.4. My suggestion was outlined by Jeff in #8470. Whatever we decide to do, this change makes it easier to transition to allowing[a, b]
to be non-concatenating (#3737) and regularization ofDict
syntax #8521.The parser should probably be changed to reject the
{}
array / dict syntax during the transition period. Would throwing an error be sufficient? This will be a hugely breaking change so I thought I would solicit some feedback on that.