That’s the purpose of having a warning in 1.1 and an error in 1.2 and only changing the behavior in 1.3: anyone who upgrades to either 1.1 or 1.2 would get detailed advance warning of the change. Even the people who hate to fix deprecation warnings and just ignore them in 1.1 would get a hard error and be forced to change their code in 1.2. There is some chance of someone going straight from 1.0 to 1.3, skipping both 1.1 and 1.2, and never reading anything on discourse or the release announcements for any Julia versions, but that seems like an acceptable risk.
3 Likes
Is it still on the table to do nothing?
For me its always more complicated to adopt to a changed behaviour than to learn a new concept and for this reason I predict that the proposed solution of transitioning the behaviour over multiple version will cause more confusion than the problem itself does now. People already get angry because they can’t find linspace in 1.0, not to think of the ruckus that will ensue after 3? different behaviours will have been described in Wikis/Tutorials/Books/Manuals/Blogs…
7 Likes
Personally I don’t mind too much unless I’m required to have local or global in front of my variables. I have a lot of scripts with a lot of variables and having that kind of annotation to be mandatory wouldn’t be great.
local data = load_data()
global results = process(data)
local plots = plot(results)
In the strategy above I would have to skip Julia 1.2 (which I guess would be fine?).
Unless that code is in a loop or other scope construct, none of those would require annotations.
1 Like
This change isn’t breaking if it’s a bugfix? I think a lot of people ran into this thinking it was a bug? This hits on the whole “what is a bugfix” really isn’t well-defined.
4 Likes
Given the amount of pushback and confusion that we’ve been getting because of the new scope behavior, I’d say not. I don’t much fancy having to deal with multiple people per day posting questions about this.
2 Likes
Calling this a bug fix would be disingenuous since it was very much intended and documented.
6 Likes
Yes, sometimes it’s difficult to say what counts as a bug fix. A good example is my recent PR that fixes a segfault, but also introduces new method ambiguities. But this is not one of those cases. This may be a fix in the sense that it changes something you greatly dislike, but the current behavior does not block anybody from getting work done (your code can still work, you just don’t like the way it looks), and changing it could absolutely make programs stop working, so it’s a breaking change.
6 Likes
Ah, I thought it was an unintended consequence found after the release.
1 Like
i seriously hope that 2.0 is not “years away”. how about next summer instead? what other breaking changes are being discussed?
my inclination would be to just suck it up, no breaking changes until 2.0, and sleep in the bed we made for ourselves by not having a longer transition between 0.7 and 1.0. hopefully we can learn from this experience.
4 Likes
I read through the comments on GitHub in the related issue and I think I can express better now what I meant by my examples. One of the main features why I understood the change is introduced it is that people want to copy-paste code between global scope and functions (e.g. when using examples from forums in their code).
Currently such copy-pasting produces an error in some cases. After this change it will work, but on the other hand silently produce a different behavior in some other cases. And although an error case (current functionality) is annoying at least it manifests itself visibly (you add global where needed and re-run the code which is cheap in interactive mode), while silently different behavior between function and global scope may lead to bugs.
Therefore - apart from a general rule (which I agree is clear) - I thought that having a reference somewhere that lists those cases would be good.
2 Likes
I suspect this thread will be quite messy if we don’t focus only on people’s opinions about the final design proposal.
2 Likes
Yes, thank you. For example if we want this design, we could consider enabling it in the REPL first and everywhere in 2.0.
3 Likes
But donn’t we have actual problem because we were focused too much to one point of view? Maybe we could start to give more time to found best solution?
I don’t know if it violates any assurance, but I’d prefer to see (a) do it in the REPL, (b) do the rest in 1.1.0 (or 1.2.0 – whatever makes sense viz a viz deprecation). Waiting for 2.0 makes little sense to me – it means engraining the problematic behavior in people’s understanding of Julia.
Ok, propose another solution. No time limit.
If we know the future that will come, isn’t something analogous to python’s from __future__ import scope_behavior possible in Julia 1.1 too?
No, very much intentional:
1 Like
Is there so to speak a “right” solution, irrespective of cost or impact on the user community?
1 Like
Yes, adding a way to opt-in to the future behavior makes sense.