…So I Put a Function in Your Function

To help address those sorts of concerns, Kotlin supports local functions:

@Composable
private fun DrawerContent(
  navController: NavController,
  scaffoldState: ScaffoldState
) {
  fun navTo(route: String) {
    navController.navigate(route) {
      popUpTo = navController.graph.startDestination
      launchSingleTop = true
    }

    scaffoldState.drawerState.close()
  }

  Column {
    DRAWER_ITEMS.forEach {
      DrawerRow(it) { navTo(it.route) }
    }
  }
}

This is a bit of code using an alpha version of Jetpack Compose, a next-generation UI toolkit for Android. Without getting into all of the details, we have a DrawerContent() function that populates a navigation drawer that slides out from one edge of the screen. We want to have a list of rows in the drawer representing places you can navigate to in the app, where DrawerRow() renders a row. Part of the logic of DrawerRow() is to respond to click events on a row by calling the supplied lambda expression. There, we call navTo() to navigate to the desired portion of the app. navTo() is implemented as a local function — its implementation appears inside of DrawerContent().

navTo() could be a peer function of DrawerContent(). However, as it turns out, the only place that navTo() is needed is here in DrawerContent(). DrawerContent() is a top-level function; having navTo() also be a top-level function clutters up the top-level namespace. We could just have the body of navTo() go directly in the lambda expression provided to DrawerRow()… but we might have other navigation UI options besides rows, such as some buttons at the top of the drawer for popular destinations. Using a local navTo() function allows that logic to be reused as needed within DrawerContent(), but only within DrawerContent(), where it is needed.