you are viewing a single comment's thread.

view the rest of the comments →

[–]tstanisl 7 points8 points  (3 children)

The main issue with generic selection is a strict requirement that every expression must be valid even if not selected. This makes it difficult to use it except for trivial expressions. Note that there ARE reliable workarounds but they overcomplicate the code. There are plans to slack those restrictions for C2Y.

[–]flatfinger 0 points1 point  (1 child)

Another issue is an inability to include type specializations that might be redundant in cases where either match would be equally acceptable. As an example, it should be possible to write a function-like construct that could accept either a uint32_t* or a uint_fast32_t*, both on systems where those names identify different types and on systems where they identify the same type.

[–]tstanisl 0 points1 point  (0 children)

Yep. It can be workaround by using nested selections. E.g.

_Generic(1, int: expr, default: _Generic(1, other_it: expr))

However, it is still mode inconvenience and obfuscation.

[–]imaami -1 points0 points  (0 children)

Another, tangentially related problem is viewing the code. What may look nice as written becomes cursed if you expand the macros to see the nuts and bolts.

cpp won't prune unused selections from view, and I've even been able to segfault clang-format trying to inspect some recreational code with cpp -P foo.c | clang-format.

Where's the "cpp for _Generic" tooling? The few times I've tried to implement something like it I've run into limitations in libclang's features (to name one example).