i guess maybe

find

and

^

at the beginning of the pattern

@jw what is your use case? Do you want to check whether regex matches string at the specified position? or something more complex involving changing internal state of Matcher? In the former case we probably could introduce new

Regex

functions, like

matchesAt(string, index): Boolean

and

matchAt(string, position): MatchResult?

, although I'm not sure we could implement them effectively on all platforms.

i forgot already. i just left j.u.regex for now and filed and issue to circle back

there's also not support for named groups yet so I figured i'd just leave it for now

i was just porting code, not writing new code, so i didn't spend a lot of time trying to figure out everything the existing code was doing

Named groups are supported on JDK8, you need to use kotlin-stdlib-jre8 which provides this extension https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/get.html

oh interesting. i did see the NamedMatchGroup type or whatever but the comment made it seem like it wasn't supported yet.

ah well that's good to know that's there, but i'm looking for an equivalent of

isName

specifically which determines whether or not a string is a keyword in the language 1 reply There’s a private API in

kotlin-reflect

for this, used to render declarations properly for toString, see

kotlin.reflect.jvm.internal.impl.renderer.KeywordStringsGenerated

@msink has left the channel

For what reason

File.forEachLine {}

is NOT

inline

? Original SO question: http://stackoverflow.com/q/44108489/3144601

@Bart has left the channel

It causes a lot of bytecode to be inlined, so we decided to leave it non-inline, and when inline is badly needed one can resort to more explicit

useLines { lines -> lines.forEach { } }

How much is "a lot"?

I think the docs should mention the workaround

My problem with that is that it is inconsistent (that was the original problem on SO)

@burak.eregar has left the channel

I just noticed that

Map.minus()

extension always creates a new Map, even if key ends up to not exist in a current map. Using logic like

return if (containsKey(key)) minus(key) else this

would save an extra allocation (for Android users). Would it be sensible to create a YouTrack issue for this? Or there are reasons not to go this way?

creating an issue can never hurt

okay 🙂 will do later. for now I created this extension helper locally )

since it's not api breaking, I would say it's a good improvement

yep. unless

containsKey()

is somehow costly or not wanted. it's a good optimization for those of us who like an immutable world 🙂

yeah it's a tradeoff

you should always avoid doing the lookup step twice

i'd be tempted to leave the behavior as-is as you could do that check yourself before calling

minus

in most cases you're not removing things from maps that don't exist

yes, that's why I almost never use

containsKey()

, usually prefer

[]

(or

get()

), but would

containsKey()

be more costly than an allocation?

hmm. you have the point, right

it is in the case where the item is in the map

but you're right that it's wasteful to allocate in the case when you're trying to remove a non-existent item

i don't think there's a perfect answer, but i lean towards the current behavior