Proposal: change `*drop` to another name

[Dmitry Atamanov]

More commonly used names in other programming languages and libraries are "free" or "destroy".

[Tyge Løvset]

Thanks for the suggestion. free is out of the question, because it normally means heap deallocation, which is something that should be done in addition to destruction only if the container was allocated on the heap.
I will reconsider destroy, as it is the most used name for it in C. Rust uses drop, which is why I used it. I can agree it is not as commonly used (yet), but Rust is making a lot of traction these days, and drop is a identifiable name. (so is destroy).

[Tyge Løvset]

I don't care much for the naming of the create/destroy idiom. In general the element to be "created" already exist, but needs to be initialized. The opposite operation doesn't normally even modify (destroy) the element - it just frees potential resources it owns and should not be used anymore. In that sense, "free" is better, but it could cause confusion:
Vec* vec = malloc(sizeof Vec); *vec = Vec_init(); Vec_push(vec, 1); ... Vec_free(vec); free(vec);
Some could believe Vec_free(p) actually also calls free(p) and/or require a heap allocated object.
I will stick with the Rust name, drop. It is both short and easy to write/read and the name describes the operation well.

(dispose is another good name, used by pascal and others).

[Dmitry Atamanov]

It's strange that you use words from Rust in the C library.
Why not new/delete from C++ stdlib?

[Dmitry Atamanov]

I'll try to explain in more detail why I don't like "drop".
In your library I see the potential to develop different iterators like C++20 ranges.
C++20 ranges implements drop_while and drop_while_view.
Another widely used Rust library, itertools, also has a lot drop* iterators.

[Tyge Løvset]

Edited:
You could also ask why are functions and type names in STC mainly from C++ STL? C works more similar to Rust than C++: Rust has default move semantics like C, no overloading, no inheritance, no constructors or special operators like C++ has.

See this post: https://stackoverflow.com/questions/62595557/how-to-implement-drop-while-on-mutable-iterator

Here, implementing drop_while in Rust actually means dropping/destroying the elements until the predicate is satisfied. Conceptually, the c++ implementation also drops/destroys the characters up to that point. So, I don't really see the naming conflict here?

fn main() {
    let s = String::from("abcdefg");
    let mut it = s.chars();
    
    // Alt 1:
    //let x = it.by_ref().skip_while(|x| *x != 'c').next();
    //println!("{:?}", x); // Some('d')
    
    it.by_ref().take_while(|x| *x != 'c').for_each(drop);
    println!("{:?}", it.next()); // "Some('d')"
}

Again, I would advice you to rather look at Rust iterators and ranges. Rust has a much simpler iterator concept than c++, i.e. it only has a init function (like begin() in c++), and a next() function. This fits the better the lower complexity of STC. In my dev branch, only *next() is now required, so c_foreach() has gotten simpler (you can still iterate from it1 to it2):

#define c_foreach3(it, C, cnt) \
    for (C##_iter it = C##_begin(&cnt); it.ref; C##_next(&it))

[Liigo Zhuang]

"free" or "destroy" have their own pair: alloc/free, create/destroy (and new/delete). so i don't think any of them is the friend of "init".

i do think "drop" is a good name: init/drop, or new/drop. (and maybe "fini" is another good one: init/fini feels well.)

[Tyge Løvset]

I will keep drop, as I like it better than destroy and other alternatives, and it is used in Rust as destructor name. There is a c_FLT_SKIPWHILE macro which works similar to Rust "skip_while" and c++ "drop_while".