Closed CosmicHorrorDev closed 1 year ago
I can see how this would make sense. I would probably rename the str
module to string
because it's an owned string. I would also like to see the re-exports because it's just too inconvenient otherwise.
ecow::{
eco_vec,
eco_format,
vec::{EcoVec, IntoIter},
string::EcoString,
/* re-exports for EcoVec and EcoString */
}
What I don't really see the value in is exporting the inline size limit. What would be the use case for accessing that constant?
While we're at restructuring: If there's a tests dir, then the src/tests.rs contents should move there too, I guess. These currently use the LIMIT constant (which I'd prefer to keep private), but I think just hardcoding 15 and adding a few extra test around 23 for big-endian is fine.
What I don't really see the value in is exporting the inline size limit.
I think it's a good idea just because it makes the max inline size transparent. I would understand making it public+semver-exempt, but people may be relying on the inline limit being at least some size while currently it can change without much of a way to inspect it
:+1: to everything else
I would be okay with an associated const on EcoString instead of a top-level const. Also, I think that INLINE_SIZE_LIMIT
is a bit verbose and long, I think LIMIT
is clear enough.
Care to meet in the middle with something like INLINE_LIMIT
? IMO public consts should have self-descriptive names while just LIMIT
is a bit vague as to what it's referring to
You're driving a hard bargain. Alright, then.
I think it would make sense to expose the inline string size limit and then have the public API be something along the lines of
The existence of
IntoIter
to me is enough to have a separatevec
module at least (and there is the chance that other iterators could be added likeDrain
)I would be up for re-exporting or exclusively exposing
EcoVec
andEcoString
in the root of the API though since they are likely going to be the most commonly use types