-
Notifications
You must be signed in to change notification settings - Fork 596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enforce required fields for builders #2087
Merged
arqunis
merged 11 commits into
serenity-rs:next
from
mkrasnitski:builder_required_fields
Aug 17, 2022
Merged
Enforce required fields for builders #2087
arqunis
merged 11 commits into
serenity-rs:next
from
mkrasnitski:builder_required_fields
Aug 17, 2022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These methods simply wrap `Self::default`. Also change any remaining usages of `Builder::default` over to `Builder::new`.
github-actions
bot
added
builder
Related to the `builder` module.
examples
Related to Serenity's examples.
framework
Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate
model
Related to the `model` module.
labels
Aug 9, 2022
arqunis
added
enhancement
An improvement to Serenity.
breaking change
The public API is changed, resulting in miscompilations or unexpected new behaviour for users
labels
Aug 17, 2022
arqunis
approved these changes
Aug 17, 2022
arqunis
pushed a commit
that referenced
this pull request
Aug 21, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
arqunis
pushed a commit
that referenced
this pull request
Sep 2, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
kangalio
pushed a commit
to kangalio/serenity
that referenced
this pull request
Sep 11, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Oct 1, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Nov 7, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
arqunis
pushed a commit
to arqunis/serenity
that referenced
this pull request
Nov 13, 2022
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Feb 28, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
May 18, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
May 30, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Sep 21, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Oct 17, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Oct 24, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
arqunis
pushed a commit
to arqunis/serenity
that referenced
this pull request
Oct 24, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
arqunis
pushed a commit
to arqunis/serenity
that referenced
this pull request
Oct 24, 2023
This commit adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of `Default` on those builders and adding a `new` method that takes the required fields as argument.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
breaking change
The public API is changed, resulting in miscompilations or unexpected new behaviour for users
builder
Related to the `builder` module.
enhancement
An improvement to Serenity.
examples
Related to Serenity's examples.
framework
Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate
model
Related to the `model` module.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds enforcement for unconditionally required fields on builders. It does so by removing the implementation of
Default
on those builders and adding anew
method that takes the required fields as argument. The following builders have been changed as such:All other builders have retained their implementations of
Default
, but I've added anew
method to them as well that simply wrapsSelf::default
. A few things to note are:EditAutoModRule
has been left untouched, however it should be noted that creating an automoderation rule has some required fields, whereas modifying one does not. Potentially it might be worth it to add a newCreateAutoModRule
builder, although that would introduce a good bit of code duplication.EditRole::new
toEditRole::from_role
to be more descriptive, and changedEditRole::new
to wrapEditRole::default
.CreateMessage
and others where one ofcontent
,embeds
, orattachments
is required). Doing so would (I think) require using a typestate pattern, so should be done in a separate PR, if at all.Bikeshedding on parameter order for the newly enforced fields in each
Builder::new
method is appreciated. I've done my best to order them based on some intuitive sense of hierarchy.