IsEmpty extension/helper method

[VelvetToroyashi]

In V6, there is the concept of "Core Entities", which more accurately reflect Discord's API surface, and do not abstract away the notion of empty/optional fields. This is useful for some scenarios, but is unfortunately data that's coalesced into null, transforming Optional<T> (and subsequently Optional<T?>, which have different semantics, but I digress) into T?.

This simpler API surface makes the library easier for the majority of end-users, lowering the barrier to entry, but can abstract away critical information that's needed sparsely, and may not warrant ripping away the entire curtain of the library's abstraction.

For this, I propose a new API method for entities, be it on the entity itself, or as some static helper method. The signature would look something like this:

public static bool IsEmpty<TEntity, TProperty>(this TEntity entity, Expression<Func<TEntity, TProperty>> memberAccess)
{
  ArgumentNullException.ThrowIfNull(entity);
  
  if (memberAccess.Type is not ExpressionType.MemberAccess)
  {
    ThrowHelper.NonMemberAccessExpression(memberAccess);
  }
  
  // Look into entity's base data and extract `Optional<TProperty>`
  return !baseProperty.HasValue;
}

This is very useful for situations such as on GUILD_CREATE, where it is possible to distinguish whether a guild is "new" (added to the guild) or not (pre-existing prior to gateway connection) by checking if unavailable is false or empty.

Under normal circumstances, this would be coalesced to null, however this may not always be the case.

Of course, the actual implementation of such an API would still need to be constructed, to which I can offer to help, or even write a proof-of-concept if need be.

This was inspired by an offhand remark I made here.

[Naamloos]

Interesting idea, I like it. Feels more clean compared to exposing the Optional to the end user. This way we can provide regular fields that can be used directly as-is, whilst still maintaining parity with the actual API.

No more property.Value.property.Value.property.Value :^)

[akiraveliara]

the premise is that we're never exposing the optional to the end user anyway, but provide them a hatch to access this information anyway; in Velvets words, without "ripping away the entire curtain of the abstraction."

[Naamloos]

though it might be a good idea to discuss why we are abstracting this information away anyway?

[VelvetToroyashi]

Simplicity first and foremost; it reduces the bar to entry (what we're known for) and makes things more convenient. It also limits architectural changes from V4/5->V6. Power users still have the option of using raw entities however.