Why does the explicit api mode require me to annotate functions of interfaces with a visiblity? Is a...

# announcements

[Paul Woitaschek]

Why does the explicit api mode require me to annotate functions of interfaces with a visiblity? Is anything but public even valid on interfaces?

[Javier]

I didn't tried, but maybe you can have private functions with a default implementation. And a public one with a default implementation which use the private one.

[pablisco]

It’s possible to have internal interfaces

[Paul Woitaschek]

@pablisco
No, that doesn't compile:

public interface MyInterface{
  internal fun hello()
}

[pablisco]

ah, missread the original question, my bad. Yeah, the visibility of the functions should inherit from the interface. You are right, that’s a bit odd then 🤔

[elizarov]

Because it is an explict mode

[Youssef Shoaib [MOD]]

And also IIRC there's some plans to support a form of private methods on interfaces or something along those lines

[christophsturm]

i disabled explicit api mode again because it made the code look so verbose. if it is meant to be a good default for most libraries then it is a bit too verbose imo

[elizarov]

There might be some form of less-visible interface members in the future, but that's irrelevant.

[elizarov]

The explicit mode is primary targeted for stable library maintainers that need to be constantly reminded when they edit any piece of their code which parts represents their public API surface.

[Paul Woitaschek]

To us our gradle modules are libraries

[Paul Woitaschek]

We have lots of them and we want to carefully think about visibility

[elizarov]

Moreover, a stable library usually has tons of documentation, so when you see a line fun foo() somewhere, it is not immediately clear whether it is public or not, since it will be preceded by pages and pages of text

[elizarov]

In a such a library an extra public does not add much verbosity

[Paul Woitaschek]

Its just too much noise on interfaces

[Paul Woitaschek]

I mean it's not that it's consequent in other places. Here we need a public on every function of an interface where only public is allowed in the first place

[pablisco]

I think there is potential use cases for internal functions in an interface as we may have certain functionality that we only want to access internally but only expose part of this functionality, in which case the public “verbosity” would be granted 🙂

[Paul Woitaschek]

But then for data class properties I get no warning when I accidentally expose a property I didn't mean to.

[elizarov]

That's explicit, though. Now as I library maintainer I don't have to remember about the context.

[elizarov]

We made an exception for data class props after revieiwing our code.

[elizarov]

They are usually dense and don't have much docs.

[pablisco]

Maybe we could have this configurable if there is demand for eliminating such restriction

[Paul Woitaschek]

With the same logic you apply to interfaces you can argue that this is necessary on overwritten methods too.

[elizarov]

That've been a lot of design discussions on specific rules and surely there are lots of tradeoffs. There's no way to define some clearcut rules that are great in everybody's minds. Needs compromises.

[Paul Woitaschek]

Or configuration options

[elizarov]

Maybe yes, maybe not. Too much configuration has its problems, too (maintenance, complexity). The very concept of having a new special mode in the language was quite controversial in itself, let alone making it configurable.

[edrd]

Quoting @Javier:

I didn't tried, but maybe you can have private functions with a default implementation. And a public one with a default implementation which use the private one.

This is possible, so this:

Here we need a public on every function of an interface where only public is allowed in the first place

is not correct.