ObjFW  History of src/OFEnumerator.h of 998339ff24279ce362e574bf382bacc9f3ea85057cdef6dfd28ee77bbfefd625

This fixes building as a module. file: [514f228b0c] check-in: [4c09929cca] user: js, branch: trunk, size: 3658 [annotate] [blame] [check-ins using] [diff]

Classes using lightweight generics should also use them for the
enumerator to allow stronger typing. file: [a48f5dd585] check-in: [f0f38b0f42] user: js, branch: trunk, size: 3677 [annotate] [blame] [check-ins using] [diff]

This is to be consistent with OFFastEnumeration. file: [570c70606c] check-in: [151e4642fe] user: js, branch: trunk, size: 3503 [annotate] [blame] [check-ins using] [diff]

__COUNTER__ does not exist in GCC 4.2, and Apple GCC 4.2 is still the
newest compiler available for macOS 10.5. file: [6f877d2d05] check-in: [ef614a225d] user: js, branch: trunk, size: 3592 [annotate] [blame] [check-ins using] [diff]

This made the Swift compiler complain. file: [8acf2a6a5e] check-in: [0428b0ecd2] user: js, branch: trunk, size: 3578 [annotate] [blame] [check-ins using] [diff]

This allows ABI stability with the fragile ABI. file: [1264743def] check-in: [496695d778] user: js, branch: trunk, size: 3581 [annotate] [blame] [check-ins using] [diff]

It's not very useful and is a problem for the Foundation bridge, as
NSEnumerator does not have it. file: [fb1ecf6b18] check-in: [7214a2c7af] user: js, branch: trunk, size: 3535 [annotate] [blame] [check-ins using] [diff]

allObjects is mutating the state of the enumerator, so should not be a
property. file: [1cb50952e0] check-in: [003c448269] user: js, branch: trunk, size: 3648 [annotate] [blame] [check-ins using] [diff]

This improves Swift compatibility. file: [ba066f3027] check-in: [f3ccf14461] user: js, branch: trunk, size: 3564 [annotate] [blame] [check-ins using] [diff]

Casts are now written like types in variable declarations. file: [e2784c6244] check-in: [4af49a13c3] user: js, branch: trunk, size: 3663 [annotate] [blame] [check-ins using] [diff]

Forgot to add 2017, even though I already did quite some changes in
2017. file: [bbb1fb080b] check-in: [44f45c2e35] user: js, branch: trunk, size: 3660 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [28dfc5f158] check-in: [cec0f072f8] user: js, branch: 0.8, size: 3659 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [fdd5f1237e] check-in: [2a27cf3000] user: js, branch: trunk, size: 3654 [annotate] [blame] [check-ins using] [diff]

Now that Clang switched to use _Nullable and _Nonnull instead of
__nullable / __nonnull, there is no longer a conflict with glibc, which
means we can just define _Nullable / _Nonnull to nothing if they are not
understood by the compiler (which did not work with __nullable /
__nonnull due to this conflict).

This also defines _Null_unspecified to nothing if unavailable. file: [74f0d63f69] check-in: [d526d938d7] user: js, branch: trunk, size: 3646 [annotate] [blame] [check-ins using] [diff]

Using __nonnull directly doesn't work on systems using glibc, as glibc
defines __nonnull as a parameterized define. While this does not fix the
problem of Clang introducing __nonnull even though it conflicts with
glibc, this at least means it's possible again to compile things with
versions of Clang that don't support __nonnull on systems with glibc. file: [30b2100737] check-in: [b7097a67b6] user: js, branch: trunk, size: 3655 [annotate] [blame] [check-ins using] [diff]