Defining a function inside if...else..end NOT as expected?

New to Julia
42

Opinions are fine. And I agree that this situation is bad and should be fixed. I have said as much both here and on the relevant GitHub issue. One constructive way to give an opinion is to simply post here or on the issue something along the lines of “I got bitten by this and would love to see this fixed.” That kind of feedback is always welcomed and does help to prioritize things when many people indicate that they’ve encountered some problem. What doesn’t help is:

  • asserting that doing something is obviously very easy
  • expressing outrage that some issue has not been addressed yet
  • implying that developers have been sitting around twiddling their thumbs just putting off fixing this one issue

If you had just said “I encountered this and it would be great to have a warning at least” then the reaction would have been “sorry about that, thanks for letting us know”. It’s the other parts of your posts that provoke pushback. In particular, if you express certainty that something must be easy to fix, then it seems fair to assume you know what you’re talking about, in which case it’s also reasonable to suppose that you might be a person who could help fix the issue. If that’s not the case, that’s ok of course, but then how can you be so sure that it’s easy to fix?

For this specific problem, the hard part is not emitting a warning but figuring out under what circumstances to emit it. Here’s a contribution you could make that requires zero programming: under what precise circumstances should code defining inner functions emit a warning? Please keep in mind all the kinds of control flow constructs that may occur, including conditionals, loops, comprehensions, closures, try/catch blocks, and goto. Also keep in mind that we generally cannot break code that currently works (including adding warnings) unless there’s strong evidence based on reasoning through the problem and inspecting code in the wild that the pattern we’re breaking is almost never used in a correct way, in which case a warning can be added, but that analysis has to be done first.

14 Likes
43

@ericphanson
Wow. Thank you. That’s awesome. I mean if anyone mentions it to me that the idea I am also suggesting in my original post is about to get solved, we could have spared some time here. I started scrolling through that page, but it was longer than what I had time for, and the title doesn’t hint at all to such a warning, so I left it there for later reading. I just don’t know why I was told twice that it is probably hard to implement and maybe I should do it myself. Either hardly anyone reads what I actually suggest here before answering to me or they also didn’t know that this warning is about to appear in the next release?..

@StefanKarpinski

  • “still I think such a warning really shouldn’t be that hard to implement.” not an assertion, but an opinion, see “I think… shouldn’t be that hard” => also it is implemented now, so it was not that hard, I guess, whatever that means.
  • It’s a serious known bug left without a warning for at least 4 years. Because of this, I lost many working hours and I can’t help thinking that I am not alone with this. Some degree of outrage is warranted, although probably not helpful, I admit that.
  • I was not implying any such behavior on part of the of the devs. Wat was bugging me and prompted me to keep writing is that my words got taken out of context twice as if I was suggesting that the original problem should be fixed by now, even though I started my post with

and I never urged the solution of the original problem, other than emphasizing that it should be prioritized.

I never did that, please quote me if you think otherwise. I haven’t even ever used the word must here. Again words are being put in my mouth that I have never said. Pleas use the quote function.

The warning got implemented, so I happened to be right about this. I never stated anything else.

I have never questioned the complexity of the original issue, and no, the last statement doesn’t follow from anything I actually wrote.

Rather issue a false positive, saying “you may not get the results you expect…” And again, something got implemented, so it was doable. About the hard or not part, it is always a dilemma, between how hard relative to how big of a problem it is if we don’t do anything about it for a few more years. Yes, one has to go through the whole list, you wrote here. And maybe more. But this is a serious issue, so it has to be done. If it is just left in there it leaves people with a lot of anger over lost work, and the impression that Julia is not the serious project one thought it would be. To me reliability is way more important than new features. And this was left there for many years without a warning. I would prioritize very differently.

That having said. Thank you for your work, I’ll probably keep using Julia. You can relax, you didn’t lose me. :rofl: But seriously, I still prefer Julia over the alternatives, and it’s time to express my appreciation over the work you invested in it. I hold my criticism, but I don’t want that you think that I am just trashing the whole project. Now that everybody hates me here, it’s time to close my lines. :sweat_smile:

Cheers

2 Likes
44

Great, I’m glad this worked out. Sorry for the time lost to a vexing bug.

5 Likes
45

No worries. That’s part of the process. And sorry if I was a bit rough in my criticism.