I am trying to optimize the loop performance by reducing the number of
bound checks. Inside the loop I compute a slice index and access two slice
indexes like this:
j := i / 2
s[j+1] = i
s[j] = i // <- I want to get rid of this bound check
I assumed that I can get rid of the second bound
low it to work using two distinct types
> that have the same underlying type is debatable. Personally, I think the
> current behavior (not allowing the conversion) is preferable.
>
> On Sun, Jul 16, 2023 at 9:02 AM Leonard Mittmann <
> leonard.mittm...@gmail.com> wrote:
>
>&
Hi everyone, I am wondering if there is efficient way to do the following
type conversion (without looping over the map):
var m = map[uint]uint{ /*...*/ }
type uintXXX uint
// this does not work
var m2 map[uintXXX]uintXXX = (map[uintXXX]uintXXX)(m)
--
You received this message because you are
things in the same term "interface".
Am Mi., 15. Dez. 2021 um 22:19 Uhr schrieb Ian Lance Taylor :
> On Wed, Dec 15, 2021 at 3:24 AM Leonard Mittmann
> wrote:
> >
> > I just learned that type constraints, which are defined as interfaces
> are actually not usable
I just learned that type constraints, which are defined as interfaces are
actually not usable in all the places "normal" interfaces can be used in.
E.g., why can a constraint interface not be uses as a struct type?
Let's say I have the func `func Smallest[T constraints.Ordered](s []T) T`.
How
The Generics proposal does not add the ability to implement binary
operators for types. Instead type sets of language types like `int` or
`uint` are proposed to allow the use of binary operators like `==` or `<`
to be used for generic parameters.
Why is this not solved by allowing types to
