rename main generic parameters

the main generic parameters on the codebase are:

T: for the type the smallvec contains
N: for the inline capacity
A: for the allocator

new proposed names:

T => Item
N => INLINE
A => Heap

names subject to change, alternatives are welcome

I'm not really sure if renaming T helps - every rust developer knows what T means. Changing it would just be making it more verbose.

I do agree that N is vague. Something like N_INLINE or INLINE_CAPACITY would be more clear.

For A, as with T, we're currently following the rust convention - breaking the convention adds more of a mental overhead for developers reading the code.
Since Allocator is new to stable though, I suppose the convention hasn't been set in stone. Maybe something like HeapAllocator/HeapStore would be better than just Stored, to make it clear that it's only used in the heap case.

what about Heap: Allocator?? I like your idea. honestly I said Stored because I ran out of ideas

having the capacity named with a underscore in it feels icky to me honestly, I feel it is too long and descriptive for what it could be. I vote for INLINE or INLINED simply

I hate single-char generics. like yeah T in our context is unequivocally the type, just as let x = 2; would be unequivocally "the number" on a function which only has one variable, but that doesn't mean it conveys any information to the developer other than "this thing". at that point we may as well rename SmallVec to S and tell downstream crates to rename it if they have a namespace conflict because it's obvious for us

if smallvec had, say, 10 generics, would we still call T T?? I don't think so. it feels like a bad practice

what about Heap: Allocator??

Yeah, you can probably tell that it's an allocator from context.

having the capacity named with a underscore in it feels icky to me honestly, I feel it is too long and descriptive for what it could be. I vote for INLINE or INLINED simply

INLINE is probably best then.

Type is still not very descriptive, maybe Item would be better (matches iterators).

yeah I like that final lineup

doing this

how is it going??

refactor: rename the main generic parameters

refactor: rename the main generic parameters (servo#749)

Since Allocator is new to stable though, I suppose the convention hasn't been set in stone. Maybe something like HeapAllocator/HeapStore would be better than just Stored, to make it clear that it's only used in the heap case.
what about Heap: Allocator?? I like your idea. honestly I said Stored because I ran out of ideas

I have a problem with the new name of A: It's called Heap. This is an incorrect assumption. A must only interface with Allocator, not necessarily be what we call "the heap"; For instance, if A is used on bare-metal, or any system that doesn't have the notion of heap for that matter, or under a (probably self-defeating, but totally possible) stack-allocating allocator.

(from #749)
I think calling the allocator something like Spilled or something similar makes more sense. Heap makes an assumption about how the allocator works. Spilled is more high-level and generic and shows the intent of this allocator, not what the allocator (rightfully or wrongfully) does (which we can't know, as any allocator is allowed).

Memory doesn't sound bad either

Escape now looking at it at 1am sounds weird

btw why are we arguing about a simple name

🏳️ 🏳️ 🏳️

whatever be the consensus, pwease update and raise PR.

@alejandro-vaz

I don't think we've reached an unanimous consensus, so ultimately I believe it's @alejandro-vaz's call. My two cents on the matter are given.

🏳️

I'll keep this open and I'll look at it in a few days and see what we should do from a more distant perspective

okay I went to first principles and we have to identify these two patterns:

types are nouns: Vec, Box, String, ...
traits are generally, though not always, adjectives: Sized, Default, ...

by following that convention, our allocator trait should actually be renamed to be an adjective, something like Allocatable, whilst our generic should be called Allocator

Let's do something shorter?

for the trait or generic??

Let's go with it and do it. If all is fine

okay I went to first principles and we have to identify these two patterns:

types are nouns: Vec, Box, String, ...

traits are generally, though not always, adjectives: Sized, Default, ...

by following that convention, our allocator trait should actually be renamed to be an adjective, something like Allocatable, whilst our generic should be called Allocator

I think this will induce confusion as, currently, convention says that the trait is named Allocator (as it is in std) (as you said yourself, "traits are generally, though not always, adjectives"), and, since we're keeping it principled, the generic is generally just named a single letter as I've pointed out before.

Other than that I don't actually dislike the idea, other than "Allocatable" being a long, difficult name

I think this will induce confusion as, currently, convention says that the trait is named Allocator (as it is in std) (as you said yourself, "traits are generally, though not always, adjectives"), and, since we're keeping it principled, the generic is generally just named a single letter as I've pointed out before.

I don't think so because we don't really export that trait, it is something only we have to know

and we already have longer trait names like Requirement and so on, it wouldn't make much difference since it is only for internal use

and single-letter generics are a mistake for semantic meaning for the developer, even if they are the mainstream convention. again, if it were public API, I'd argue that we should stick to the convention, but it is only internal use for us

and single-letter generics are a mistake for semantic meaning for the developer, even if they are the mainstream convention.

Agreed.

again, if it were public API, I'd argue that we should stick to the convention, but it is only internal use for us

How is it not part of the public API? The whole point of the feature is to have functions that take custom allocators. This means interfacing publicly with whichever new name we give to A, no?

Furthermore, I analysed this thread again.

A trait can very much so be a noun as much as it can be an adjective. All it depends on is in whatever the trait does. For a service/role, which is exactly our case, a noun absolutely fits and is the better choice.
Allocatable is most definitely incorrect here. Allocatable refers to something that can be allocated. That is not what we're referring to. We're referring to something that has the traits of something that allocates. That's an allocator. In our case, the trait and the type define semantically the exact same thing, as the trait not only restricts the type but defines exactly and perfectly what it would take and the role of the type - They're essentially the same thing, the trait is just 'the correct language term' to do what we want. A is a particular defined type of a generic Allocator, the value that the programmer initialises with is a particular instance of A, and Allocator is exactly that, a generic hint that whatever we accept must be able to allocate. A is just a concrete implementation of that. Nothing wrong with this other than maybe the fact that A isn't something we like as a name (even though it's rust standard), but honestly the failing quest of finding a better name probably speaks volumes about whether it makes sense to do so. The only thing that is 'allocatable' (and thus, allocated) is whatever data the user has in the vector (and its type), which is any data (and any type).

Honestly, I propose we keep with the standard compliant version we had and have on v1, at the very least for A and Allocator and perhaps T. It's standard, simple, predictable and uncomplicated. I understand the quest for something more sensible but there doesn't seem to exist such an option and we're walking in circles trying to solve a non-issue at this point. Any Rust programmer knows what T, N and A are. The other ideas for the most part just seem more confusing or outright incorrect.

Allocatable is most definitely incorrect here. Allocatable refers to something that can be allocated. That is not what we're referring to. We're referring to something that has the traits of something that allocates.

yeah I think you are right there

How is it not part of the public API? The whole point of the feature is to have functions that take custom allocators. This means interfacing publicly with whichever new name we give to A, no?

our custom Allocator trait is not part of the public API, it is for our internal stuff

I understand the quest for something more sensible but there doesn't seem to exist such an option and we're walking in circles trying to solve a non-issue at this point. Any Rust programmer knows what T, N and A are. The other ideas for the most part just seem more confusing or outright incorrect.

fact, this is going nowhere

once we are on rc or even in releases if necessary we can change it, it doesn't bother much

our custom Allocator trait is not part of the public API, it is for our internal stuff

While this is true, my point is that our public API takes custom allocators as arguments, so while the trait isn't exported, its name is indeed referenced in our public API (see https://github.com/servo/rust-smallvec/blob/v2/src/lib.rs#L104).

Additionally, while this issue is closed, I want to remind that #749 got pushed and so we are currently using Item (agreeable), INLINE (very decent) and Heap (misleading).

Navigation Menu

Repository navigation

rename main generic parameters #731

14 remaining items

🏳️

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

rename main generic parameters #731

Description

Activity

bolshoytoster commented on Oct 4, 2026

alejandro-vaz commented on Oct 4, 2026

bolshoytoster commented on Oct 4, 2026

alejandro-vaz commented on Oct 4, 2026

GauravPawar101 commented on Oct 8, 2026

alejandro-vaz commented on Oct 8, 2026

pedrodesu commented on Oct 8, 2026

14 remaining items

alejandro-vaz commented on Oct 8, 2026

alejandro-vaz commented on Oct 8, 2026

GauravPawar101 commented on Oct 9, 2026

pedrodesu commented on Oct 9, 2026

alejandro-vaz commented on Oct 9, 2026

🏳️

alejandro-vaz commented on Oct 14, 2026

GauravPawar101 commented on Oct 14, 2026

alejandro-vaz commented on Oct 14, 2026

GauravPawar101 commented on Oct 14, 2026

pedrodesu commented on Oct 14, 2026

alejandro-vaz commented on Oct 14, 2026

pedrodesu commented on Oct 15, 2026

alejandro-vaz commented on Oct 15, 2026

pedrodesu commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions