You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a lot of enumerations where the variants have names that are identical to the FFI names, which is bad style and looks weird.
However, the SQLite FFI names are still pretty important, and it would be a mistake for us not to clearly explain what each variant is. These are how the official docs will refer to these values, and it will help folks figure out what SQLite docs to read to understand the value, and what variant the official docs are referring to when they reference some variant.
That is, for a given enumeration, users should to easily be able to both: determine the Rust name for a given FFI name, and vice versa. (It also would be an enormous breaking change if we change all of this at once without some consideration for easy migration path)
To solve these issues, I propose that we do the following steps:
Rename the variants to use CamelCase names.
Reference the FFI names in the documentation of the variants.
Add inherent constants with the SQLITE_ to both allow people to find them, and significantly reduce the breakage this change would cause.
I don't mind doing this, but @gwenn, do you have strong objections to this?
Example
For example, on Limit steps 1 and 2 would look like:
// ... attributes/docs omitted ...pubenumLimit{/// The maximum size of any string or BLOB or table row, in bytes.////// Equivalent to `SQLITE_LIMIT_LENGTH` from the C API.Length = ffi::SQLITE_LIMIT_LENGTH,/// The maximum length of an SQL statement, in bytes.////// Equivalent to `SQLITE_LIMIT_SQL_LENGTH` from the C API.SqlLength = ffi::SQLITE_LIMIT_SQL_LENGTH,/// The maximum number of columns in a table definition or in the result set/// of a SELECT or the maximum number of columns in an index or in an/// ORDER BY or GROUP BY clause.////// Equivalent to `SQLITE_LIMIT_COLUMN` from the C API.Columns = ffi::SQLITE_LIMIT_COLUMN,// ... rest of the limits ...}
And then step 3 would be providing the following:
implLimit{/// An alias for [`Limit::Length`], provided for compatibility with the C API.pubconstSQLITE_LIMIT_LENGTH:Self = Self::Length;/// An alias for [`Limit::SqlLength`], provided for compatibility with the C API.pubconstSQLITE_LIMIT_SQL_LENGTH:Self = Self::SqlLength;/// An alias for [`Limit::Columns`], provided for compatibility with the C API.pubconstSQLITE_LIMIT_COLUMN:Self = Self::Columns;// ... rest of the limits ...}
The text was updated successfully, but these errors were encountered:
We have a lot of enumerations where the variants have names that are identical to the FFI names, which is bad style and looks weird.
However, the SQLite FFI names are still pretty important, and it would be a mistake for us not to clearly explain what each variant is. These are how the official docs will refer to these values, and it will help folks figure out what SQLite docs to read to understand the value, and what variant the official docs are referring to when they reference some variant.
That is, for a given enumeration, users should to easily be able to both: determine the Rust name for a given FFI name, and vice versa. (It also would be an enormous breaking change if we change all of this at once without some consideration for easy migration path)
To solve these issues, I propose that we do the following steps:
SQLITE_
to both allow people to find them, and significantly reduce the breakage this change would cause.I don't mind doing this, but @gwenn, do you have strong objections to this?
Example
For example, on
Limit
steps 1 and 2 would look like:And then step 3 would be providing the following:
The text was updated successfully, but these errors were encountered: