Does anyone know the motivation behind `FloatItera...

# announcements

[Ben Butterworth]

Does anyone know the motivation behind FloatIterator?, we already have Iterator<Float> https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-float-iterator/

[fred.deschenes]

I'm guessing it's like the IntStream/FloatStream/etc and it's just an optimized version that doesn't need to box/unbox the value each time

[nanodeath]

that would also be my guess

[Ben Butterworth]

I’d like to investigate/ learn more, could you suggest an approach?

[Casey Brooks]

There are classes like FloatArray, FloatRange, FloatProgression, etc. for all the primitive types, for similar reasons. Seems like, generally, all data structures of primitives have dedicated classes so the compiler can optimize them to avoid boxing/unboxing

[nanodeath]

https://docs.oracle.com/javase/8/docs/api/java/util/stream/DoubleStream.html the docs are sparse for DoubleStream, but it applies here too

[Ben Butterworth]

public interface DoubleStream extends BaseStream<Double,*DoubleStream*> mind blown

[nanodeath]

public interface BaseStream<T,S extends BaseStream<T,S>>

I know how to use streams, but dive into the implementation and it quickly becomes ... well, more complicated than it seems like it should be. that's one thing I like about Sequences -- mostly they have easy-to-understand implementations

[Ben Butterworth]

In swift, we wouldn’t need the extra S because within BaseStream, it is already usable (Self is the implementing type). I guess this isn’t possible with Kotlin? The closest is reified types, but this is for functions only

[Zach Klippenstein (he/him) [MOD]]

Yep, kotlin does not have self types.