if we could have a list of use case,
written in g1, with an explanation about why it can t be generalized,
we could check any proposal that at first it answers them,
then enter into more detailed study and proposals ?
I m reluctant to provide examples about concurrency,
i have some ideas of what functions i need,
i m not hot to write them...
At least here is some func i wish was generalized
- concurrentSync(sync func(...)..., concurrency int) (wrappedSync
func(...)...., cancel chan struct{})
- concurrentAsync(async func(..., jobDoneSignal chan struct{})...,
concurrency int) (wrappedSync func(..., jobDoneSignal chan struct{})...,
cancel chan struct{})
(this sig is soooo long...)
- throttle (call a func at most once every D time.Duration)
throttle(f func(...)..., d time.Duration, head bool) (throttledFunc
func(...)..., cancel chan struct{})
- mustNorErr ?
then stuff like map.Each, slice.Each etc.
That being said, in
func Add1(key $A, val $B, m map[$A]$B) {
m[$A] = $B
return
}
It will trigger a runtime error if $A is of type []byte (met that error
yesterday with an interface{} type).
Sooooo, as the bloat already exists with interface{}, is it something to
keep or to remove ?
More generally at which extent runtime 42 errors are acceptable,
or should be used to compromise a prefect/ideal model in order to
simplify/fix <something in the model> ?
On Sunday, July 23, 2017 at 10:17:04 AM UTC+2, meta keule wrote:
>
>
> Hi,
>
> here is a proposal for an alternative to Generics for Go2:
>
> https://github.com/golang/go/issues/21132
>
> Please discuss!
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
