1

I’m dealing with Freetype error enums that are returned as error codes by freetype functions as Int32s, but themselves get imported by Swift as Ints. This means I can’t test a returned error code against cases of the error enum without integer casting. SR-3999 describes the issue, but it was put off “until Swift 4”. what’s the status of this now?

2

It's most likely "it didn't happen, so it probably won't ever happen, because it would be pretty source-breaking". If you want to gather data and put together an evolution proposal for Swift 5, though…

3

what does “gathering data” entail? all I know is i’m currently resorting to some c macro trickery to get these freetype enums working correctly with Swift.

#define FT_ERRORDEF( e, v, s )  e = v,
#define FT_ERROR_START_LIST     enum {
#define FT_ERROR_END_LIST       FT_ERR_CAT( FT_ERR_PREFIX, Max ), \
    _swiftABIForceSignedInt32 = -1 \
} FT_ErrorCase;

#include FT_FREETYPE_H

#undef FTERRORS_H_
...
4

I think we'd want some sense of how many Swift projects would be broken if we changed the current behavior, and how many anonymous enums in C are meant to be used with values of type int (as opposed to unsigned or char or int8_t, which would all still need conversions).

5

I don’t know where to begin with this

I would think a lot of C library authors consider enums interchangeable with int so they write their interfaces to take int32_t some some variation instead of the enum type. or it could just be FreeType though.

Related: any reason why #defines are also imported as Ints? this causes basically the same problem in that the library assumes they’re Int32s, but Swift sees them as Ints. never mind this seems like a bug in the library that no one probably noticed because of C’s implicit integer casts