Visibility Modifiers
A brief rundown on visibility modifiers in Kotlin, with an emphasis on internal and what a module is
— — — — — — — — — — — — — — —
THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.
— — — — — — — — — — — — — — —

Tags: #FYI
This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.
It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.
This is pretty boring, so let’s get it over with. Classes, objects, interfaces, constructors, functions, properties and their setters can have visibility modifiers. Getters always have the same visibility as the property.
There are four visibility modifiers in Kotlin: private, protected, internal and public. The default visibility is public. Kotlin does not have package private visibility, a decision which is actively debated.
The only new one is internal, which means that the member is visible within the same module. More specifically, a module is a set of Kotlin files compiled together:
- an IntelliJ IDEA module
- a Maven project
- a Gradle source set (with the exception that the
testsource set can access the internal declarations ofmain) - a set of files compiled with one invocation of the Ant task
Packages
Functions, properties and classes, objects and interfaces can be declared at the “top-level” directly inside a package:

