Suppressing with a comment seems like the perfect solution then.

It disables the warning and provides future travelers the reasoning behind it

Don't you have to suppress per class or method then?

Yes. You're going out of your way to subvert the normal way of doing things so you have to pay a cost

I wonder how big of a deal those allocations are on L+. Heard its VM is quite improved

I suppose something like this would be better off as a CI code lint rule.. But I don't think there are any (sonar) for kotlin

@jw Here's what I think about when I say there should be a way to get the functional code without iterator allocation: https://publicobject.com/2016/12/19/seductive-code/

There was a discussion before 1.0 about whether the functional helpers in the stdlib should use iterators. The decision was to use iterators because they throw ConcurrentModificationExceptions which is a good thing.

I argued against it but I can also understand the reasoning

C# has a similar situation with LINQ, actually even worse because they don't have inline functions. Still, ReSharper will recommend turning loops into LINQ.

I guess it's better to look to the future though, not necessarily current restrictions

Especially since the language will be stuck with them

VM has gotten much better in some ways with newer Android, so in a few years I imagine it'll get even better (as will it's hardware) and be even less of an issue

@gildor

You can also use explicit comparison of Boolean:

if (flag1 && (flag2 || someFlag == true))

More clean and native then elvis or extension function

Well, this would produce a different behavior compared to my examples. In my case

someFlag.orTrue()

would resolve to

true

when

someFlag == null

, but in your example

someFlag == true

would resolve to

false

if this flag is null. I.e.

.orTrue()

and

.orFalse()

allow me to finetune behavior of null boolean values. This is rarely needed, but there are cases when this helps... Otherwise your suggestion in certainly nicer 🙂

Hi all,

kotlin.text.all

doc says

Returns true if all characters match the given predicate.

however

true

is returned also always for empty texts

eg

"".all { it.isDigit() }
true

is it by design? if so, shouldn’t it be mentioned in documentation?

yes, it’s by design, empty set is still a set, and all elements matches predicate, there just happens to be none 🙂

ok, thanks

you can try

toIntOrNull

if you can use 1.1-beta and that’s what you’re actually trying to do

actually

.all

behavior matches my case, just want to confirm

kotlinc complains about using classes like

java.lang.Long

, but there doesn't seem to be an equivalent to

java.lang.Long.BYTES

in

kotlin.Long

. am I missing something?

kotlin doesn't expose all of java's stuff since kotlin can also be compiled to other targets than java where certain java specific things don't make sense. if you're targeting java you can safely use java's built-in types and ignore/suppress the warning

@kirillrakhman when I use a short in a "portable" kotlin library I shouldn't expect it to store exactly 16 bits?

what about Int or Long when you compile to native?

what's the size of an int in C?

Size of an

int

in C is platform-dependent (in practice ranges from 16 bits to 64 bits). However, in Kotlin

Int

is always 32 bits.

@kirillrakhman who cares about what C decided in the 1970s? there's

stdint.h

for modern C, golang has https://golang.org/ref/spec#Numeric_types and rust has https://doc.rust-lang.org/book/primitive-types.html#numeric-types

given its history, I would have expected kotlin to stick to same names as java as currently documented in https://kotlinlang.org/docs/reference/basic-types.html#numbers regardless of platform