* Changed Guild#DefaultChannel to resolve the first accessible channel
Resolves#776
This change is inline with hammerandchisel/discord-api-docs#329
RestGuild#DefaultChannelId is now obsolete and will throw a
NotSupportedException.
* RestGuild#DefaultChannelId will fall back to the guild ID
Adding an exception here would be a breaking change, so this was agreed
to fall back to the previous behavior, which would just return the guild
ID.
IChannel.IsNsfw will now return false when being used on any channel
that is not an ITextChannel. When being used on an ITextChannel, this
will now account for the API flag, and fall back to the channel name.
(this is gross design, thanks discord)
Seeing as D.NET will warn you about an impending BadRequest if you try and send an empty field, why not make it warn about the impending BadRequest if you try and send a whitespace field?
This provides tests to ensure the following:
- Creating a Color
- Creating a Default Color
- Accessing a Color's Raw Value
- Accessing a Color's translated RGB values
* Update client.cs
Let's not have the client be a local variable, hm?
* Update complete.cs
* Update complete.cs
* Update client.cs and complete.cs
Let's not have the client be a local variable, hm?
* Fix potential nullref in embedBuilder value setter
* Null check on footer iconUrl
* Adding checks for the other URL properties
* Adding IsNullOrUri extension
* Setting StringExtensions as internal
* Add embed builder extensions
People in #dotnet_discord-net suggested that this should be part of
the lib after I demonstrated it
* Move some extensions into EmbedBuilder [2]
Apparently git didn't like that previous commit
* Fix error with EmbedBuilderExtensions
A summary of issues which happened:
- Git decided to add an amend commit (I told it to quit?)
- VS Code thinks everything is an error so it wasn't helpful
- dotnet decided to think there was no error until I deleted all
build outputs and rebuild
Sometimes I question my ability to use version control properly.
* Allow commands to return a Task<RuntimeResult>
This allows bot developers to centralize command result logic by
using result data whether the command as successful or not.
Example usage:
```csharp
var _result = await Commands.ExecuteAsync(context, argPos);
if (_result is RuntimeResult result)
{
await message.Channel.SendMessageAsync(result.Reason);
}
else if (!_result.IsSuccess)
{
// Previous error handling
}
```
The RuntimeResult class can be subclassed too, for example:
```csharp
var _result = await Commands.ExecuteAsync(context, argPos);
if (_result is MySubclassedResult result)
{
var builder = new EmbedBuilder();
for (var pair in result.Data)
{
builder.AddField(pair.Key, pair.Value, true);
}
await message.Channel.SendMessageAsync("", embed: builder);
}
else if (_result is RuntimeResult result)
{
await message.Channel.SendMessageAsync(result.Reason);
}
else if (!_result.IsSuccess)
{
// Previous error handling
}
```
* Make RuntimeResult's ctor protected
* Make RuntimeResult abstract
It never really made sense to have it instantiable in the first place,
frankly.
* Allow arbitrary attributes to be added to commands
I still don't approve adding type info back into commands, so
I decided to use this solution for allowing arbitrary attributes to be
added to commands.
Add attributes property to ParameterBuilder
Add Attributes properties to info types
* Why on earth git
* Add using for system so that Attribute can be used
* C#7 features in commands, CommandInfo in ModuleBase
* Update TypeReaders with C#7 features and IServiceProvider
* Add best-choice command selection to CommandService
* Normalize type reader scores correctly
* Fix logic error and rebase onto dev
* Change GetMethod for SetMethod in ReflectionUtils
Should be checking against setters, not getters
* Ensure args/params scores do not overwhelm Priority
* Remove possibility of NaNs
