Feature request: provide crate functions as type-associated functions.

[nathan-at-least]

The current API relies on crate functions:

use enum_iterator::{all, Sequence};

#[derive(Debug, PartialEq, Sequence)]
enum Day { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday }

fn main() {
    for day in all::<Day>() {
        println!("{day:?}");
    }
}

My personal aesthetic taste is for type-associated functions:

#[derive(Debug, PartialEq, enum_iterator::Sequence)]
enum Day { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday }

fn main() {
    for day in Day::all() {
        println!("{day:?}");
    }
}

Aside from just the call-site ergonomics, this would place all of the associated methods onto the API docs for Day, making it more obvious to library consumers that these features were available.

Thoughts?

[stephaneyfx]

Sorry for the late answer.

Type associated functions are problematic in the context of code generated by the Sequence macro. If the type it is derived for already has associated functions with the same name, a compiler error will ensue. If more functions are added to the code generation and are defined as type associated functions, the risk of name collision increases and code that used to compile may not be accepted anymore. The Sequence macro would need a way to opt out of generating specific functions or to rename them. This mine field does not exist when defining most of the functionality of enum-iterator as free functions.

A middle ground approach could be to define all functions in the Sequence trait (or a separate SequenceExt trait). This avoids the issue of name collision at definition time. However, ambiguous calls may arise if a type implements Sequence and other traits that have identical function names. This issue is not specific to Sequence and is pervasive in Rust.

For this crate, I made the conscious decision to avoid all these potential breakage situations for end users by defining most functions at the crate level. This is not a novel approach. itertools does that too (in fact, it defines both free functions and functions in an extension trait). futures also defines free functions, while others are defined in an extension trait. As the history of itertools reveals, breakage (when using the extension trait instead of free functions) has happened several times as other traits (Iterator) have had new functions added to them.

I understand that this design decision may make the available functions less discoverable. Would adding a comment to the Sequence trait alleviate this problem? This comment would point to where most of the Sequence-related functions can be found. Let me know if you think that's helpful and I can open a PR.