Use generics from go 1.18

[GRbit]

It's 1.18 now.
Are you planning update your code to use generics? It will improve speed dramatically.

I know that some of the functions can't be properly updated due to the fact that interfaces are more flexible than generics, but there are a lot of functions that could be updated. And because of https://pkg.go.dev/golang.org/x/exp/maps and https://pkg.go.dev/golang.org/x/exp/slices some functions aren't useful right now. So, there are a lot of work =)

Will you accept any pull requests with generics?

[thoas]

@GRbit yes, I would accept PRs and I'm currently working on a v2 to use generics :)

[valiangspe]

Looking forward to this. Greatly appreciated

[andig]

I‘ve just gone through the exercise and replaced funk by generics, mainly /x/exp/slices, which proved for my uses straightforward. The main omission in Go regarding slices is missing Map/ Reduce/ Filter afaikt.

[metalrex100]

@thoas create please v2 branch so it became possible to contribute.

[thoas]

@metalrex100 I will, it will be available next week :)

[metalrex100]

@thoas is there any functions that you did not implement so far with generics?
I may provide PR's with their implementation 🙂

[andig]

Note golang/go#45955 (comment) which links https://github.com/luraim/fun

[metalrex100]

Hum, when @thoas told that branch with generics will be available for contribution next week, I did not expect it will be at the end of the week (not available so far).
GO 1.18 has been released more than 2 weeks ago and 2 most popular packages with helpers (go-funk and lo) can't provide operational maintenance for generics.

V2 branch with generics support could be released asap, so interested in generics community would provide PR's for helpers they are interested in.

Instead currently everyone, who wants to use generics helpers, but would like to use it with well-known package instead of self-written implementation are blocked by maintainers of the go-funk and lo packages.

IMO if you are an author of the demanded by community package and you don't have time to actively maintain package - need to find more maintainers.

[andig]

Instead currently everyone, who wants to use generics helpers, but would like to use it with well-known package instead of self-written implementation are blocked by maintainers of the go-funk and lo packages.

I don't feel blocked. Instead I can continue using this excellent module or move to any generics-based package including my ohne patches until something more mature comes up. Big thank you to @thoas for all his work sofar.

[metalrex100]

@andig when codebase is pretty big - it require to spend much time on replacing your self-written solutions with some well-known package.

[thoas]

@andig when codebase is pretty big - it require to spend much time on replacing your self-written solutions with some well-known package.

Yes, it takes more time than expected I will have a first draft a the end of the week. I have created a v2 branch, you can send me some PRs if you want.

I don't want to rush it, since it will be a complete rewrite and a lot of BC :)

[metalrex100]

@thoas it will be actually almost another lib. Methods names will be still the same))

[thoas]

@thoas it will be actually almost another lib. Methods names will be still the same))

Yes, that's why it will be separated to a complete new branch and installed via gomod using github.com/thoas/go-funk/v2/. There is a lot of things to rewrite and we must focus on basic utilities first.

[metalrex100]

@thoas indeed. New implementation also must be placed in v2 folder according to GO versioning system.

[metalrex100]

Or you want to deal with versioning by always having 2 branches instead of single master with 2 directories: root and v2?