So I thought about it some more, and since I plan on adding a AllocationCreateInfo::memory_type_filter field, that would then again leave us with 2 ways to specify the same thing. The allocator would turn the MemoryLocationPreference and HostAccessType into a MemoryTypeFilter and OR it together with AllocationCreateInfo::memory_type_filter.

This might be a bit hard to understand for the user, which is why I think we could simplify this even more and only have the memory_type_filter, with presets as associated constants of MemoryTypeFilter, and with it implementing BitOr. Another benefit would be that you only need to import one type. The downside would be that we can't ever do more complex branching on the MemoryLocationPreference and HostAccessType inside the allocator in the future.

How does this look?

AllocationCreateInfo {
    memory_type_filter: MemoryTypeFilter::PREFER_HOST | MemoryTypeFilter::HOST_SEQUENTIAL_WRITE,
    ..Default::default()
}

Or maybe even

AllocationCreateInfo {
    memory_type_filter: MemoryTypeFilter::STAGING,
    ..Default::default()
}

I would prefer not to complicate things at the possible prospect of doing more black magic inside the allocator. I don't think that's that useful anyway. If we ever need to create a MemoryTypeFilter from some parameters, we can just make that an associated function of the type. Easier for the compiler because it doesn't need to inline all the logic inside the allocator itself, easier for someone implementing an allocator, and easier for a user to understand the logic.

Nice, I like it! Using Rust features in ways that don't work for a C API!

Everything good, thanks!