It would be a breaking change tho
they can add a deprecation notice on release and just remove in some minor update i think
#Add utils like `GuildMember.bannableBy(member)`
thorny otter
It would be a breaking change tho
oblique yew
they can add a deprecation notice on release and just remove in some minor updat...
deprecation notice can be added in minor releases but by semver, it can only be removed in a major version (v15)
thorny otter
deprecation notice can be added in minor releases but by semver, it can only be ...
Ok. Tbh I don't strictly follow semver but do whatever feels like the best approach. But yeah they can do that in this version and remove it going into the next one.
pallid ridge
Yeah we can add a deprecation warning and remove it in v15. I am currently on holiday, if no one opens a pr before, I can do it as soon as i get back
foggy belfry
<GuildMember>.bannableBy() sounds worse than <GuildMember>.bannable when it comes to if they can be banned by the bot. bannableBy should always have a parameter, else the name of the method would be wrong. You have to tell by whom if it is named -By
pallid ridge
So you suggest keeping the getter?
trail nebula
yeah i think it should be kept
foggy belfry
The getter can internally just call bannableBy(guild.members.me) though to not write redundant code
pallid ridge
Yeah that's the idea
thorny otter
The getter can internally just call bannableBy(guild.members.me) though to not w...
yeah this sounds like a good thing
pallid ridge
Working on this rn. Do you think the method should throw an error if the member is not cached or just return false?
oh nvm, I see that similar methods just return a falsy value so I guess I'll do the same
oblique yew
would that be really correct 
pallid ridge
smoky bay
orientate yourself on the other methods
pallid ridge
Mmh yeah but I'm seeing that some of them throws an "uncached me" error while others just return a falsy value. I'll search more and see whether keeping one or the other
jovial flare
I would throw instead
If your client is uncached in a guild and you're checking a permission that returns a falsey value that you are definitely sure is true, that could trip you up
That's my thoughts on the matter
pallid ridge
So, we have getters such as GuildMember#bannable, GuildChannel#manageable etc... that check if the client can ban a member, manage a channel and so on. I think it would be fantastic to have something like GuildMember#bannableBy(member) that check if a member is bannable by another one, check if a member can manage a channel, etc... It could replace the getters and have the member option that defaults to the client or they could be just added alongside them.
oblique yew
From what i know, the library is shifting away from such utility methods unfortunately and rather recommends the user to make those themselves as top level functions
pallid ridge
Yeah but since utils like .bannable are already present, having something like bannableBy() wouldn't require so much...
smoky pewter
Something like bannableBy is probably reasonable since there's a lot of checks there. I don't see one being created for "member can manage a channel" - since that would be a single channel.permissionsFor(user).has("MANAGE_CHANNELS")
oblique yew
that makes sense
pallid ridge
Something like bannableBy is probably reasonable since there's a lot of checks t...
Mmh yeah I see
Btw, do you think it should be created apart from the present getter or, as I said in the description, with the member parameter optional that defaults to the client?
pallid ridge
Yeah, I meant to keep the getter or not
oblique yew
I guess the getter could essentially just re-use that new function
heavy hollow
.bannable could be replaced by bannableBy() without any params. So if no member param is specified, it would return if the member is bannable by the client.