Status of SR-3999

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?

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…

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 {
    _swiftABIForceSignedInt32 = -1 \
} FT_ErrorCase;

#include FT_FREETYPE_H

#undef FTERRORS_H_

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).

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