Previously the argument '@user#0000' return None.
To fix this, as this is a common user error, an extra check was added
to remove the first character from the argument if this is an '@'.
Discord names may not contain an '@' anyways.
The original code was too aggressive in ensuring that the channel
positions are correct and within bounds. Unfortunately, for Discord
this number is merely a guess and there can be gaps that cause the
position number to be greater than the number of channels currently
in that sorting bucket.
One such example of this is when a channel is deleted and created. When
this happens, the positions are not updated (presumably because Discord
considers this to be too expensive). Sadly this means that if a user
were to create a channel, delete a channel, and then create another one
then there will be gaps in the position sequence.
More concretely, consider the following example:
Channels with position [0, 1, 2, 3, 4]. A new channel is created so it
inherits the maximum position giving us [0, 1, 2, 3, 4, 5]. We delete
a channel that's smaller than the maximum so our list now looks like
[0, 1, 2, 4, 5]. Next time we create a channel we will further
increment the gap, giving us [0, 1, 2, 4, 5, 6]. If a user would want
to move the channel with position 4 to be after position 6 (so in this
case that value would 7) then the library would erroneously raise an
error because it assumed too much about the data integrity.
Luckily, the library upon actually doing the request fixes the channel
positions so everything goes back to normal like it was intended. That
is to say, [0, 1, 2, 3, 4, 5].
This adds manage_permissions, view_channel, and use_external_emojis
aliases to Permissions. It should be noted that to prevent breaking
changes and for sake of usefulness, aliases are not included in
the `__iter__` for either Permissions or PermissionOverwrite.
Fixes#2496
The first thing someone will ask when someone sees this method is
"Why doesn't `send` just accept `Attachment`?". This question is fair
but it has an issue: exception propagation becomes confusing.
When we save a file and write it to memory an HTTP request is sent
similar to other API calls. Like all HTTP requests, these can fail.
Since these requests denote failure using HTTPException, if it were to
originate within `send` then it becomes confusing to know whether the
attachment saving itself failed or whether the sending failed.
For that reason, and to keep in-line with only 1 type of HTTP call per
method, it doesn't make sense for `send` to support `Attachment`.
