all: consider using type-params

[sbinet]

Type parameters (a.k.a. "generics") may land in Go-1.18.

we might want to consider using those for:

• [ ] groot/rhist.TH1{I,F,D}
• [ ] groot/rcont.Array{C,D,F,I,L,L64,S}
• [ ] groot/rtree ?
• [ ] fmom.P4
• [x] sliceop/f64s (and use the new slices package from stdlib)
• [ ] fwk.Store
• [ ] hbook.H1D, hbook.H2D, ...

[sbinet]

for groot/rcont.Array (and groot/rbytes.{R,W}Buffer}) one would need a way to type-switch on the type parameter. ie: https://github.com/golang/go/issues/45380

[dolmen]

Just be aware that Go 1.18 generics are not faster for all types.

See this detailed analysis: https://planetscale.com/blog/generics-can-make-your-go-code-slower

[sbinet]

yep.

for example, I am not too sure about the rhist.TH1x (where x is a numeric type) as all the code has already been generated and it's a fixed set. (more or less the same argument for the hbook.H{1,2}x types where x could be intXX (but one would need some more special code to handle weights) or floatXX)

[sbinet]

fwk.Store might make the most sense (parametrized fwk.Get[T](store, k) and fwk.Put[T](store, k, v) functions, like the the groot/riofs.Get[T] top-level function)

[dolmen]

What is the status of the fwk project? Is API stability required? Is it still work in progress?

[sbinet]

all the packages in go-hep.org/x/hep inherit the v0.x.y tag from the hep module, so no API stability is required. of course, we try not to modify everything for the sake of modifying things :) (and we try to provide go fmt -r rewrite rules or eg scripts to ease the migration when possible, but that isn't a requirement either)

for API changes, it's best to discuss changes on the mailing list before actually doing the work.