Skip to content
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

CSV encoder docu shows numbers instead of characters as defaults #18999

Closed
scMarkus opened this issue Oct 31, 2023 · 1 comment
Closed

CSV encoder docu shows numbers instead of characters as defaults #18999

scMarkus opened this issue Oct 31, 2023 · 1 comment
Labels
type: bug A code related bug.

Comments

@scMarkus
Copy link
Contributor

A note for the community

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

I noticed the default values in the documentation for the CSV encoder are shown as numeric values. As the one having implemented the configuration option I would be happy change the visualization to a character one since this is what one would configure. Still at this point in time I am not sure how to properly do this.

The respective code can be found here:

const fn default_delimiter() -> u8 {
b','
}
const fn default_escape() -> u8 {
b'"'
}
const fn default_double_quote() -> bool {
true
}
const fn default_capacity() -> usize {
8 * (1 << 10)
}
impl Default for CsvSerializerOptions {
fn default() -> Self {
Self {
delimiter: default_delimiter(),
double_quote: default_double_quote(),
escape: default_escape(),
quote: default_escape(),
quote_style: QuoteStyle::default(),
capacity: default_capacity(),
fields: Vec::new(),
}
}
}

Is this possible / desired?

Configuration

none

Version

0.33.0

Debug Output

No response

Example Data

No response

Additional Context

No response

References

No response

@scMarkus scMarkus added the type: bug A code related bug. label Oct 31, 2023
@scMarkus
Copy link
Contributor Author

just found #18669 . closing in favor of the other one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A code related bug.
Projects
None yet
Development

No branches or pull requests

1 participant