Fernando Cacciola wrote:
I can test it with gcc (4.4.1) in a Debian Linux Box, but not today (8pm already here). And probably not until next Monday.
OK. I just did it, and it also works with gcc 4.4.1
I'm certainly missing something. Clearly, the change you committed right before freeze changed a finite amount of files. What's wrong with reverting those files into the state they had immediately before your commit?
While "I really hated the idea of going back to 2 headers" might be a good technical argument at a different time, do we really want to spend time trying yet another alternative solution at this point?
If it were just a matter of reverting N files to a previous version I would just do it. But it isn't. I need to revert 2 files, BUT ALSO 1.Manually edit-back "optional.hpp", which included "none_t.hpp" but now includes "none.hpp" 2.Manually edit-back those test files which included "none.hpp" explicitly and now they doesn't. 3.Manually re-edit the documentation to state that "none.hpp" must be included separately. Granted, I can avoid 1,2 and 3 there by going back to the 2 headers but keeping "optional.hpp" *updated*, that is, including "none.hpp". But that renders the point of having two separate headers totally useless. I totally understand that doing a last minute fix which delays the release even longer is annoying, but IMHO is even more annoying to release something knowing it has a problem just because we don't want to spend a few additional days clearing up anything that may leak after the fix. I'm afraid that's just the way our industry works, but I don't but like it. Also, unlike the problematic in-a-rush fix that caused the problem before, I've given this fix a lot of attention, and it comes with a test, so I could tested it locally on 3 different platforms and I will test it on a fourth today. And finally, Thomas is off until Wednesday anyway, so what's the point in rushing just now when we can do whatever it takes to make sure this fix will really work? Best Fernando