I'd expect any call to

.copy

to allocate a new instance

Well you can't generically call copy, so you're always dealing with a concrete data class type, so you know whether you need to call copy or not.

I know, but I mean that compiler could generate a

copy

which is smart enough to not copy when current value is equal to the new one

I'd expect any call to .copy to allocate a new instance

Usually when you working with an immutable data you don't rely on reference equality, but rely on

equals()

instead, so it wouldn't matter

or if it would, then you're likely using immutable objects in a wrong way (I guess)

sure, but this is somewhat unexpected behavior to me regardless. I think it would be assuming something that they don't want to assume. You could just do

val v2 = if (v1.v == 1) v1 else v1.copy(v = 1)

I do see your point but I think the stdlib and language in general was designed to be lean and orthogonal and let you do exactly what you want with their building blocks, not provide an exact feature for everything everyone might want

I understand this. I guess that JVM developers in general are more used to this paradigm which you describe. But in FP-languages you're almost don't think about this stuff and get these optimizations for free. At least it wouldn't create another copy in Clojure and Haskell. If i'm not mistaken.

writing it by hand is possible, but if I specify more than one (2,3, etc) properties to modify in

copy

- doing manual checks becomes tedioius...

fair. I don't think they'd want to modify core behavior like this, as it has the potential to break existing code. Maybe, as always, a compiler plugin or something would be possible. But I think they're also hesitant to provide compiler plugins so readily, which I understand. They're work to maintain, and you have to consider every edge case of how multiple compiler plugins would interact with each other

anyway, that's just a thought.

Right!

I also recall that there was some work around Persistent collections in Kotlin (a separate library) - maybe that could be done there...

@dimsuz What about mutable data classes?

what about get operator

[0...x]

to retrieve a substring from a String?

you could write your own…

Of course, you could implement every suggestion in this channel yourself. That's not the point though.

of course. one could just sit around waiting for jetbrains, or someone else to maybe implement something or just take the 2 or 3 minutes it’d take to write that and move on with life.

if you think I'll sit around waiting for jb, you are wrong. I'll continue coding, this is just something that popup in my mind during coding and I thought "oh, that'd be nice to have", but of course is not vital. It's just a suggestion to make kotlin always greater and greater. I work on many projects, and I'd like it to be available via stlib instead than starting another one for all these kinds of sugar code. Also I think that having it available via stlib would benefit much more people than having in one of my repo.. This kind of reactions and attitude leave me perplexed, especially coming from senior members like you.. I dont know why suggestions/features requests get misunderstood..

I find jetbrains really cool because they do listen a lot the community, that's also why I usually care about proposing such sugar/insignificant requests

@elect Currently there's

slice

function which you can use with ranges:

string.slice(from..toInclusive)

I like the operator suggetion

yeah, I've also implemented the operator on my own before, literally just delegating through to the

substring

function (I guess now there's

slice

which would be better). Is there a reason that it's not already implemented as an operator? It seems very expressive to me what

str[0..3]

would do

probably no one filed a YT ticket

@kevinmost the size of the string may not be known at compile time. what do you expect the operator to return in the case the string length is under the range expressed?

I think if it returned

String?

it'd be useful otherwise it may have to throw an exception if out of range.

I'd expect it to throw, yeah

isn't that what

string.slice(0..3)

does anyway?

I would literally expect the whole implementation to be

operator fun String.get(range: IntRange) = slice(range)

yeah, I guess it's what it does.

The use case I needed this for was day 3 of advent of code, and no, they wouldn't be literal bounds.

I haven't come across this in actual production code, so I don't know if there are "real" use cases.