[Feature Request] Turn Guild.features into an integer

[apacheli]

Description Make guild.features a bit integer instead of an array of strings for version 8.

Why This is Needed An array of strings is wasteful and since server boosting was added, guild.features is more likely to be filled with that data. It's also more flexible to use integers instead of string constants from my experience at least.

Alternatives Considered I do have something implemented into my library which turns it into an integer. This is what I have as an alternative:

// constants.ts
export enum GuildFeatures {
  ANIMATED_ICON          = 1 << 0,
  BANNER                 = 1 << 1,
  COMMERCE               = 1 << 2,
  DISCOVERABLE           = 1 << 3,
  FEATURABLE             = 1 << 4,
  INVITE_SPLASH          = 1 << 5,
  NEWS                   = 1 << 6,
  PARTNERED              = 1 << 7,
  PUBLIC                 = 1 << 8,
  PUBLIC_DISABLED        = 1 << 9,
  VANITY_URL             = 1 << 10,
  VERIFIED               = 1 << 11,
  VIP_REGIONS            = 1 << 12,
  WELCOME_SCREEN_ENABLED = 1 << 13
}

// guild.ts
let features = 0;
for (const feature of guild.features) {
  features |= GuildFeatures[feature];
}

Additional Details

[Rapptz]

This will suffer from the same problem that permissions suffered from as Discord adds and removes features, which is quite often.

[jhgg]

v8 ship has sailed, and these are strings because we have many guild features, we'd run out of bits.

[apacheli]

v8 ship has sailed, and these are strings because we have many guild features, we'd run out of bits.

Are you implying that it isn't possible to use the same workaround as you did with permission bits? Discord definitely has the capability to use string-serialized numbers to overcome the bit integer limitation.

This will suffer from the same problem that permissions suffered from as Discord adds and removes features, which is quite often.

I'm only aware of 13 guild features—the ones which are documented. This is far below the amount of permissions we have documented, so we wouldn't be facing that issue anytime soon.

[Taarek]

There is quite a few internal ones too.

[RedDaedalus]

There seems to be no benefit to moving from an array to a string at the cost of duplicating the information being sent. I can see why this would be nice to have but adding a features_new field seems wasteful and redundant. Would be nice for v9 though I suppose.

[apacheli]

There is quite a few internal ones too.

Bit-shifting aren't going to be affected by internal ones. They can skip some shifts as they did with INLINE_REPLY (15, ..., 19, etc).

There seems to be no benefit to moving from an array to a string at the cost of duplicating the information being sent. I can see why this would be nice to have but adding a features_new field seems wasteful and redundant. Would be nice for v9 though I suppose.

I'm not sure where you got the idea that the information would be duplicated. Version 8 is still relatively new, so it's probably the best time to suggest changes to the API.

[Skillz4Killz]

Although I like the idea of it being an integer and I may very well change my library to do it like that, I still believe changing it now after v8 has been released/documented would be a breaking change and therefore must bump to v9.