It’d be nice if there was a consistent standard for vendoring a subset of packages. That way you could have the benefits of code re-use, while still maintaining a reference to where the code came from, and avoiding the dangers of that code being modified by a malicious actor.
I wouldn’t use it for a one-liner like this, but it’d be nice to have for one-file rarely-changing packages so you could avoid adding bloat to the dependency graph.
I’m really hoping this will be included as a built-in in a future version of Go, ala the Go issue 45624 that you linked to in the README. I like the spelling &callLike(v), for example &int(42) or &time.Now(), but ptr(42) or new(int, 42) or similar would work too.
Using a library for this seems leftpad-ish: too small to pull in as a 3rd party dependency, but you might not bother if you have to write func ptr[T any](v T) *T { return &v } in every package where you use it might get a bit old.
That said, I prefer a new generic built in to allowing new(int, 42) or &int(42). The two value new form is unique even though it could just be a normal generic function, and the &int(42) form has problems with confusing results from taking pointers to functions.
Interesting usage of generics! 👏
I’ve been toying with it myself for a few weeks now here https://github.com/gtramontina/go-extlib. I’d appreciate any feedback or thoughts.
100% test coverage, wow.
I laughed when I saw this comment. I laughed again—and louder—when I saw who wrote this comment. Nicely done.
Looks cool but please don’t import this.. it’s a 3 line implementation
Very leftpad-esque
It’d be nice if there was a consistent standard for vendoring a subset of packages. That way you could have the benefits of code re-use, while still maintaining a reference to where the code came from, and avoiding the dangers of that code being modified by a malicious actor.
I wouldn’t use it for a one-liner like this, but it’d be nice to have for one-file rarely-changing packages so you could avoid adding bloat to the dependency graph.
I’m really hoping this will be included as a built-in in a future version of Go, ala the Go issue 45624 that you linked to in the README. I like the spelling
&callLike(v), for example&int(42)or&time.Now(), butptr(42)ornew(int, 42)or similar would work too.Using a library for this seems leftpad-ish: too small to pull in as a 3rd party dependency, but you might not bother if you have to write
func ptr[T any](v T) *T { return &v }in every package where you use it might get a bit old.Yes, as an advocate of avoiding dependencies you could write in an afternoon, this definitely falls under my threshold. Most people should just write their own version if they want to use something like it.
That said, I prefer a new generic built in to allowing
new(int, 42)or&int(42). The two value new form is unique even though it could just be a normal generic function, and the&int(42)form has problems with confusing results from taking pointers to functions.Yeah, fair reasoning. I’m good with a generic
ptr(x)builtin!Interesting usage of generics! 👏 I’ve been toying with it myself for a few weeks now here https://github.com/gtramontina/go-extlib. I’d appreciate any feedback or thoughts.
I also found generics useful for casting: https://paste.sr.ht/~minus/daceaaab08f4fdf838a9c671286041198dfe711b#main.go