Feature Request: Type-Directed Omission (Enum Dot Syntax)

Language Design
1

As I’ve been diving into various other programming languages, this one small feature stood out to me as sorely missing from my beloved Kotlin. In Swift, for example, you are able to reference enumerations through a nifty dot-syntax that makes code less redundant and more clear. I could see a similar language feature in Kotlin being especially helpful when using frameworks, such as with Android development.

Example (from Swift):

myAlert.preferredStyle = UIAlertController.Style.alert

Shortens to:

myAlert.preferredStyle = .alert

Although it would be nice anywhere we use enums, many people like how clean it makes their switch statements (Kotlin example w/ TDO):

return when (date.calendar[.DAY_OF_WEEK]) {
    .SUNDAY -> "Sun"
    .MONDAY -> "Mon"
    .TUESDAY -> "Tues"
    .WEDNESDAY -> "Wed"
    .THURSDAY -> "Thurs"
    .FRIDAY -> "Fri"
    .SATURDAY -> "Sat"
    else -> ""
}

I know it’s a small thing, but I see some value in adding some form of TDO in future iterations of Kotlin. Thoughts?

4 Likes
2

There was some discussion of this a few months back.

There was discussion of conflicting enums, import [...] as, typealias, and readability.

IMHO this kind of change has some potential cons and has possible alternative solutions (if the issue of readability of the enum is impactful enough). I’d also throw in minus 100 points.

It might be worth considering proposing this feature in a heavily limited form, like only available in a when clause–which was at some point planned for Kotlin (see Refer to enums by short name?)

And you can always import the enum with a wild card:

import somepackage.Color.*

fun main() {
   val c: Color = BLUE
   val message = when (c) {
      BLUE -> "It's blue"
      RED -> "It's red"
   }
   println(message)
}
1 Like
3

In terms of questioning how impactful or necessary it is, it’s hard for me to argue. On the one hand, I see the potential readability enhancements as similar to some of the standard functions such as apply and run. On the other hand, I also have a strong background in Perl, so I have a high tolerance for unreadable shorthand and extensive sugar :slight_smile: so the minus 100 points concept is a good exercise.

I’d be interested in flushing out the potential cons. I believe the scope is already fairly strict in Swift; the shorthand generally only works in three cases (that I am aware of): setting properties, passing arguments, and equality checks.

In the case of setting properties, it is already very clear for the complier which exact enum class you are referencing:

val param = .WRAP_CONTENT     // compiler error
val param: LinearLayout.LayoutParams = .WRAP_CONTENT     // succeeds
view.layoutParams = .WRAP_CONTENT     // succeeds

In regards to passing arguments, I would expect the Swift compiler and IDE would have a slightly easier time since arguments are generally named. Since Kotlin doesn’t require naming of arguments, it could potentially make sense to only allow a dot syntax on named arguments or through some other logical restriction.

Importing the enum class achieves a similar end result, though it is a nice distinction that through a dot-syntax the scope is limited and therefore limits potential conflicting imports without having to import xyz as w.

1 Like