Does Kotlin have an equivalent of the new Java feature:

if (obj instanceOf String myString) {
  // myString
}

I know I can do

as

and get a smart cast but I can’t give it a new name in Kotlin, right?

The point is, you don't need to give it a new name, you can just use the same smart-casted name.

giving it a new name improves readability actually.. see this case:

Object obj = "hello";
if (obj instanceof String string) {
    // work with 'string'
} else if (obj instanceof Integer integer) {
    // work with 'integer'
} else {
    // throw
}

If you give a proper name for the object in the first place, it is still the same thing after the smart cast so it has no reason to have a different name. Your example is not a real life example, it has no semantics, so we can't really judge from it. Do you have an example where a new name actually improves readability?

If you're doing enough that readability is an issue surely that's a sign that you should extract it?

when (obj) {
is String -> handleString(obj)
}
...
private fun handleString(newName: String) {
// work with 'newName`

Also including types of things in the names of things is rather bad practice. That's like calling a variable

iNumber

to signal in the name it is an

int

. 🤢 Otherwise as the others said, give the overall variable a proper name that is handy in all branches or extract methods.

Yeah so the proper name in my case is

stringOrInteger

. I think we could also just say Java’s feature is more convenient in this specific use case.

Well, you can say that and we can all disagree to that. 😉

stringOrInteger

an equally bad name as

iNumber

. The types should not be part of the name, the name should express semantics. For example

input

or

argument

or

parameter

or whether matches your case. That's what Joffrey meant when he said that your example is too generic and not a sane real-world use-case. 🙂

Without more context, a name like

stringOrInteger

is usually a pretty terrible name. It gives you no semantic meaning as to what the value is meant to represent (unless you are effectively designing your own type system, but even then, I have a hard time seeing how a type of "string or integer" is remotely useful).

i agree. more context needed. also if you reallyy wanted to go down that rabbit hole you can just do

.let { stupidName -> }

I can only support the arguments of the others here, variable name should describe the purpose, not type.

I am surprised none of you can imagine any use case where the new name for the smart cast is useful. Just to give more context. I am literally writing a CSV output processor that is completely agnostic of any “purpose” and can get strings/numbers as an input. The type literally is the only thing I know about the value. Sure I could also call it

input

or

value

. Even then, it is just nicer in Java where I can start by calling it a

value

and in the smart casted branches I can call it

numberValue

or

textValue

. If you still don’t see how useful this feature can be then I don’t know what else to say. I am a bit disappointed at how “radically” you folks had to express your “correct” opinion but oh well.

Noone here was radical or tried to enforce their opinion as "correct" upon you. We just have a different opinion from what you have shown and you should respect that instead of now starting to attack us, calling us radical and so on. If you think it is a cool feature, suggest it to the language committee and see what they say. In the meantime you were provided with multiple alternatives, like using

.let

or using helper methods where you can freely use different names.

1. Completely disregarding my use case and calling it “not sane” seems a bit over the top to me so that’s what I mean by “radical”. 2. I agree I can suggest it as a new feature. 3. I thank all you for providing alternative solutions.

you can say that and we can all disagree to that

I think saying things like this is pretty confrontational. You are somehow implying that everyone except me agrees with you which I doubt. But whatever. Not going to waste mine or anybody else’s time on this further.

I think saying things like this is pretty confrontational. You are somehow implying that everyone except me agrees with you which I doubt.

I'm not at all implying anything similar at all. I said "we can", not "we do". You were the one saying we all don't see a use-case where it is helpful and attacked us for having a different opinion than you. But yeah, let's stop here. 🙂

@poohbar I think your first point is where a lot of this is breaking down, and it seems to stem from not everyone being on the same page. You claim that we're disregarding your use case, and others (myself included) claim this is essentially an XY problem. Ultimately, from my perspective, it doesn't appear that you have presented your use case. You stated you have a use case that involves X (getting a different name for the same thing). In response, several people said the issue actually appears to be Y (the naming was wrong to start with) and fixing that would make X moot. You then never clarified what the use case that involved X is (this is where I think a lot of the confusion is: you appear to be claiming X is the use case, whereas others that have commented appear to be claiming how X is used is the use case). Perhaps if you could clarify better either how X is used (the use case others are seeking) or how X is in and of itself a use case that could be helpful.

I am asking how can I do something and the answer is that I don’t need to. Why not just say that it is not possible?

that’s already been explained - the smart cast works the way it works, reusing the existing variable as a different type. Changing the name is not currently possible with smart cast. Workarounds are possible as noted above.

Because "it's not possible" is not actually accurate in this case. There may be a perfectly elegant and idiomatic way to do what you're trying, we just don't know what that is. If your question is "how can I write Java in Kotlin" then yes, the answer is you can't.

Fair points. I think creating methods or using

let

are good solutions. 👍

I am asking how can I do something and the answer is that I don’t need to. Why not just say that it is not possible?

That was implied. I'm sorry if that was not obvious.

You could achieve the same thing using

if (obj is String) {
    val myString: String = obj
}

But is isn't clear what your end goal is here. Do you just want another variable? Use

val

or

let

. Do you want Java syntax? Not possible (at least not currently). Do you just want elegant usage? No need to do anything, as smart cast covers that very elegantly. And that can go on and on depending on so many things.