'premium_subscriber' should be a boolean

[quinchs]

When implementing our library, I've noticed an odd type choice for Role tags. premium_subscriber acts like a bool but has a type of null. Nowhere else in the discord api have I seen this system used.

How its defined

{
    "premium_subscriber": null, // is the subscriber role.
}

{
    // field isn't here meaning it isn't the subscriber role.
}

Maybe this should be looked over again and changed to be a boolean property?

[SinisterRectus]

I understand why the value is null, but as far as I am aware, this is the only place in the API where null indicates the existence of something rather than an absence. Because of this edge-case, I have to re-engineer my JSON parsing. If other people have solved this problem and moved on, please forgive my ignorance, but in my experience, there is no elegant solution here, and I don't think that this inconsistency is fairly justified by an implementation detail.

---

A little bit more about my own experience:

In Lua (and probably other languages), there is no equivalent of JavaScript's explicit null or Python's explicit None. There is a nil type in Lua, but this is more equivalent to JavaScript's undefined. This presents a bit of a problem when working with JSON.

Popular libraries such as cjson and dkjson use custom objects as a stand-in for an explicit null value. This helps with interoperability, but can be a footgun for at least two reasons: (1) The null objects of two different JSON modules are not equal. That is, cjson.null ~= dkjson.null. I have seen some confused souls try to use two different JSON modules in their bots and null mismatches do manifest. (2) These null objects are not falsey. Thus, if null then evaluates to true, leading to potentially confusing logic.

My Discord library uses an explicit a null object in raw JSON data; however, everywhere that this JSON data is consumed by the class API, null is passed-through as nil. For example, when a presence update is received where avatar is null, the cached user.avatar is set to nil to indicate that the user no longer has an avatar. I could just allow the null values to pass-through as they are. This is what lacord does. But given the issues enumerated above, my library does not expose explicit null values to keep things simpler for my users. The addition of a new meaning for null complicates this process.

I will probably eventually come up with a solution for all of this, and if anyone wants to talk about that, we can move to a different forum, but it would be nice if the consistency was ironed out on the API side.

[Mehgugs]

Overloading the json models with semantics like this means that cjson's parsing is now not sufficient for me either.

[erkinalp]

It is null because it is privacy-gated away from users other than self.

[MinnDevelopment]

@erkinalp no this has nothing to do with privacy since it's a role tag, not a user property. I think you are mixing something up here.

[quinchs]

Taken from discord by night#1337

it is intentionally an undefined check for future proofing. making this a boolean limits our ability to add a value to it later. role tags are not generally booleans

[SinisterRectus]

I guess I will intentionally not implement this then.

[Zoddo]

Discord could maybe return a static snowflake (like an internal application ID as we have seen in other cases) instead of null. This will ease things with these languages that don't have separate null/undefined values

[Mehgugs]

Once again discord forgets they have a versioned api.

[quinchs]

Yep... They could always just put a premium_subscriber_role snowflake on the guild object and make it optional