named operators for bitwise is horrid

bit manipulation code looks like a joke now

i'd much rather named operators for boolean logic and retain the symbolic bitwise ones

Agree with you that named bitwise operators look horrid @jw, I think it all becomes less readable. However it’s something that is used sparsely in codebases so it’s arguable wether that justifies it’s own operator. Especially when I think it’s more important to avoid issues like

a || b

vs

a | b

(with

a

and

b

being booleans) where one is short-circuit and the other is not.

yep. good point!

@apatrida wouldn't an event stream be an example of a sequence called only ones?

@voddan: no idea, I don’t have an example that fits the model other than ones in the stdlib that are already constructed this way, to allow one time asking for the iterator. A transactional style, read once and mark completed, would require more than just iterator() method to work.

A proposal for the stdlib: extension methods for the AtomicXxx classes to allow them to be used as property delegates

E.g.

var timeout : Int by AtomicInteger(1000)

I think that's a bit specific. it would better fit in a kotlin-concurrent artifact

and it's not too hard to write yourself

There is already a kotlin.concurrent in the stdlib with support for java.util.concurrent locks, conditions, read/write locks, etc. Why not atomics too?

In my experience they are used more frequently that read/write locks

I see, that's a valid argument

thought: would it be useful to include

component1() = start

and

component2() = endInclusive

extensions for

ClosedRange<T>

,

IntRange

, etc? I tend to use

IntRange

and friends whenever a start/end pair is required, and the omission of destructuring operators seems odd

Not really sure if I would expect that behaviour

why, for instance, should a range not be destructured by it’s represented range? e.g.

val (a,b,c) = 1..10

where a = 1, b =2 and c =3

I therefor think it’s best to omit those functions for ranges as it probably isn’t crystal clear what destructuring of a range suppose to do

I think of a range as an efficient sequence of elements

if I want to pass a start/end pair I use a pair. E.g.

10 to 20

An extension function of

Pair<Int,Int>.asRange(): IntRange

could be useful

Or

IntRange.limits(): Pair<Int,Int>

then you could do

val (a,b) = (1..10).limits()

that would make more sense to me indeed, first converting it to a Pair

I like the

limits()

suggestion

https://kotlinlang.slack.com/archives/stdlib/p1451993473000509 Could you share some detailed example of delegating to an

AtomicInteger

usage? I wonder if you're willing to use only

get

and

set

methods (available with delegation), would

@Volatile var

fit better?

Is there a side-effect method when chaining stream processing methods that I'm missing? basically

forEach

but as a non-terminal.

usually called

peek

or

onEach

or

doOnEach

or something...

example:

inputDir.walk()
    .filter { it.isFile && it.name.endsWith(".txt") }
    .peek { println("Moving $it to $outputDir") }
    .forEach { moveFile(it, File(outputDir, it.toRelativeString(inputDir))) }

Nice idea, can also help a lot for debugging purposes. I think peek() should be avoided as a name as it might collide with Queue interface in Java.