Fix #563: Odd dependency cycle#570
Conversation
There was no discussion other than lone comment from friendly Microsoft Issue Bot and I'm curious to see what breaks, if anything.
|
Yay, nothing broke in tests! |
|
Ping. This has been up for almost two weeks without any comments. I'd like to see this merged (or rejected, given sufficient reason) before I work on #544 again, to not let it bitrot again. |
|
Sorry for the delay, @janisozaur -- I have this queued for review this week. |
ghost
left a comment
There was a problem hiding this comment.
If this is going to be left empty, should we even bother keeping this method at all, or should we remove all mention of it?
ghost
left a comment
There was a problem hiding this comment.
Remove the function from project if it has no purpose
|
@janisozaur -- Your analysis seems spot on. Thanks, and nicely done. That being said, I want to bring in @joshkoon since he introduced that destructor during some refactoring back in Oct 2018, and there might be some context there that both of us are missing. @joshkoon -- This was code you wrote ten months ago, so if you have nothing more to add here, I completely understand. I just thought it might be useful to see if there was a specific scenario that you were trying to account for with calling |
|
@pi1024e fair point, addressed. |
|
Ping. |
|
I spoke with @joshkoon about this change in-person on Friday, and he believed that it was probably a safe change to make, but thought that verifying behavior in multi-instance scenarios would be worthwhile before merging it in. Since you're on Mac OS, I'll do some local verification today and provided that things look good, we'll merge this in tomorrow. |
HowardWolosky
left a comment
There was a problem hiding this comment.
Looks good. Thanks for your patience with the validation.
There was no discussion other than lone comment from friendly Microsoft Issue Bot and I'm curious to see what breaks, if anything.
Resolves #563