Closed mikezackles closed 3 years ago
I'd like to get some more feedback that this is a problem before removing the static_assert
, IMO the better diagnostics outweighs this potential problem. Do you mind giving me a bit more context, what lead you to hit this problem?
I totally understand not wanting to remove the static_assert
, and I don't think you should (unless there's some equivalent alternative). My thought was to add some additional unchecked macros for this situation, but I can also understand not wanting to complicate things. Something along the lines of BOOST_LEAF_ASSIGN_UNCHECKED
etc.
I'm experimenting with porting some code over from Outcome that uses lambdas fairly liberally, and creating named variables for each is a good bit of extra work/clutter. If I understand correctly this is an issue with passing lambdas inline to any function that might fail, which seems like a reasonably common pattern.
For me it's easy enough to define my own macros until I can move to c++20, but it seemed like something that might be nice to have documented in the issues for other people that run into it. No big deal if there's no fix on your end.
I got convinced that this is a problem. It is now fixed on develop
, I also added a unit test. See https://github.com/boostorg/leaf/commit/e9eb0323c5c00a358bbda4cb453c95bae68657d5. Thanks!
Awesome! Thank you!
Figured out a way to put back the static_assert
without breaking use with lambdas, see https://github.com/boostorg/leaf/commit/4a11277356c663f6035acee86ac79e873e9fe0e1.
Up until c++20, the uses of
decltype
in the static asserts forBOOST_LEAF_ASSIGN
andBOOST_LEAF_CHECK
prevent patterns likeBOOST_LEAF_AUTO(foo, create([&] { ... }()))
(lambda expression in an unevaluated context). I thought this might be a concern since this library targets c++11. Maybe unchecked versions would make sense?Anyway, thanks for a useful tool!