<https://twitter.com/kotlin/status/1383084043676311558> Starting from 1.4.20, you can create a ‘Path...

# announcements

[user]

https://twitter.com/kotlin/status/1383084043676311558
Starting from 1.4.20, you can create a ‘Path’ with the ‘/’ operator (currently experimental):

#KotlinTips

https://pbs.twimg.com/media/EzGzm5fW8AQPZ08.jpg▾

Twitter

[James Richardson]

Is it just me or is kotlin just chucking in stuff really fast. I'm not sure that some of these things are actually that useful. This, firstNotNullOfOrNull... just because you can write lots of extension functions and infix operators doesn't mean you should, at least in the core library. Less is more, right?

[nanodeath]

I kinda like the path one. Paths.get(...).resolve(foo).resolve(bar).resolve(baz) is so bad. but also...I think .resolve(foo/bar/baz) also works, so 🤷‍♂️

[Milan Hruban]

firstNotNullOfOrNull is quite useful in my opinion, I do have exactly that function in my "util" library right now.
The '/' operator for Path I don't like at all

[James Richardson]

I dont doubt all these things are useful to some, but there are infinity single expression things that might be useful to.some... but maybe they shouldn't all go in a stdlib, else it will be chock-a-block of rarely used things that are hard to remove.

[Shawn]

Is it just me, or have people complained about adding things that they don’t personally use to stdlibs since the dawn of programming languages? Nobody is advocating for adding every possible function under the sun to Kotlin, but firstNotNullOfOrNull is a pretty common pattern that substantial number of developers have had to reimplement (myself included).

The path thing is pretty ergonomic imho but more importantly, it’s still an experimental API… and the point of an experiment is to test things. Maybe folks will use it, maybe it’s a bad idea; we’ll see in due time. It’s not being thrown in without consideration.

[nanodeath]

JetBrains isn't infallible but also I'm sure they've thought about this and have review processes and I generally trust those

[Oliver.O]

Python's pathlib has provided Path classes and the / operator since version 3.4 released in 2014. I've been working with these extensively and found them quite useful (Linux only). They're probably even more useful when dealing with diverse operating systems having different path separators such as Linux/Windows.

[Nir]

/ for paths is really nice. Both python and C++ have it.

[Nir]

One of the first things I added myself via extension function when I started using Kotlin.

[Nir]

I've seen all kinds of alternatives and IME they are all just pretty bad, / ought to be extremely intuitive to the average developer.

[nanodeath]

mostly I'm just excited for Path extension functions. kinda hated having to convert every Path to a File if I wanted access to all those handy File extension methods

[Nir]

I guess in my mind, a Path should just be a Path, it becomes a File when you actually open it to some purpose, but I don't know if that's the design in this case.

[nanodeath]

I'm regularly confused on when to use File vs Path

[nanodeath]

seems like Path is preferred for new code?

[nanodeath]

and using the nio APIs

[Casey Brooks]

Keep in mind that a good majority of these “extraneous extensions” in the stdlib are inline and don’t impact your application size unless you use them. So if you don’t like it, just don’t use it; it’s not hurting your app at all

[nanodeath]

inline functions still exist as regular functions in the jar though, right?

[Casey Brooks]

A lot of them are marked InlineOnly, which I believe keeps them out of the runtime jar and only available on the compile classpath

[ilya.gorbunov]

@Casey Brooks, no inline-only functions are still functions in the jar. They may get removed from the resulting application jar or apk with dead-code elimination tools, such as ProGuard or R8.

[James Richardson]

Well, given a fixed set of people working on JetBrains products, I'd much rather an IntelliJ or Kotlin compiler that doesn't crash, in preference to all these bits and bobs, and all the other Java & Scala copying stuff that's being rapidly added. I guess that's not a consensus view, by the looks of it.

[Matteo Mirk]

One doesn’t exclude the other: I guess there are different teams woking on stdlib, on the compiler, etc.

[Stephan Schroeder]

so what your saying is, i can write something like val path = Path("Dir").div("SubDir").div("file.txt") . I read about this literally on the same day I read Effective Kotlin's (https://leanpub.com/effectivekotlin ) item 12: "Operator meaning should be consistent with its function name". Well, I guess "devided by" kind of fits. (on the other hand, the thing that is diveded by is the operator itself and not the operand 🤔)