@gildor I'm going to do that pretty often, I'd like to avoid another pair of parenthesis and indentation

I don’t think that this is useful function for stdlib. also about naming

applyOnEach

would be better than

atEach

well, it was a proposal, I'm gonna use it in the meanwhile

thanks, I'll take also the naming

I understand, but this is my point, that function can be useful, but if you want to add it to stdlib you would like to have consistent solution, so you need not only onEach, but probably forEach, map, flatMap and all other collection extensions

yeah, it makes sense

And don’t forget that many of those extensions are different for collections and sequences

well, honestly the effort for that it's over the line for me for what I'd get, but I wanted to throw it as a suggestion in case someone would like to pick it up and do something about

ps: I also had another function `apply`ing on specific indices, called

at

.. I'd change it to

applyAt

for coherence

also, sometimes I have a really huge amount of enum usage in a compact section

I'd love to keep code minimalist by temporarily having available all the values without the Enum istance as receiver

ex:

enum class VkImageLayout { UNDEFINED, ..

and then:

with(VkImageLayout) {
        val a = UNDEFINED
        ...

I dont want to

as

it at

import

, because there are still places in the same file where I'd like it plain, i.e:

VkImageLayout.UNDEFINED

neither I want to import them all directly, because I dont want to create noise with the rest of the file

There's a feature request for this already, where it would infer the enum type from the context.

do you have it handy?

I'm not sure if there's a single place to track it, but it's talked about here: https://discuss.kotlinlang.org/t/enum-value-verbosity/4241/6

And it's in https://drive.google.com/file/d/0BwAovUlww0CmVmNQTXd4TTdKYUU/view.

Hi, when building a library, should I declare a dependency on kostlin-stdlib via

compileOnly

or

compile

in gradle? The former prevents version conflicts and kotlin runtime warnings, but the latter ensures that apps using my library will find stdlib classes when being run with “just”

java

.

If you publish a library the artifact should have dependency information, and the user's build tool will fetch the kotlin library for them.

compile

doesn't include the library in the compiled binary by default unless you intentionally build a fat jar.

Thanks @karelpeeters

Why pow only useable in 'Double' and 'Float' types?

And why pow is an extension function, whats the problem to include pow in kotlin.math?

but pow extension function already part of kotlin.math

why it shouldn’t be extension function? It looks like more idiomatic API. You raise some value to the power of argument

I agree, it's really annoying there's no function for integer powers.

I think it’s because of historical reasons

Yeah Java doesn't have one either, and there's no JVM instruction for it.

but maybe make sense to add just an alias for Kotlin with int