A modern programming language that makes developers happier.

kotlinlang

*suggestion:* support private/protected keywords on _interfaces_ protected would mean accessible by anything that extends/implements the interface via _this_.

This is not a proposal, it's merely an idea. A proposal can look like a KEEP for example (<https://github.com/Kotlin/KEEP/blob/master/proposals/inline-classes.md>)

The proposal covers objectives, motivation and details of implementation on the different platforms such as JVM and JS. 

probably better just to create a feature request on <http://kotl.in/issue|kotl.in/issue>

well, started here to check the water temperature

Things that are private are usually implementation detail so personally I don't think it's necessary or a good idea to specify in an interface. Protected are similar in that way but I guess it's useful when writing default functions. Can you give an example of a use case?

yeah but, didn't java core just get `private` in interfaces? a lot of my use cases off the top of my head for this piece involve testable implementation details, for example making protected methods in interfaces that aren't meant to be public for but accessible for testing purposes. Time logic methods are a good example, I might want something like `alreadyEnded()` which does a calculation with `now()` however in order to test this I might want a protected method like `beforeEnd( Instant )` which accepts `now` but allows me to test it with other values. extending of an interface would allow for such methods to be on a base interface, and then only made use of later.

I have had things asside from tests though, it's just the first thing that enters my head.

I would consider top level extension functions perfect candidates for private interface functions. But I think you want to introduce properties that are backed by a field? 

I think it’s all part of a huge feature for traits…

so my next step on this should be to create an issue in the tracker?

If you think you can design the feature, discuss your motivation for why it should be implemented, look at potential similarities with other languages, and analyse how it could be implemented on different platforms, document your findings, and be critical of the feature while doing this,
Consider writing a KEEP. 

If not, yes, make an issue tracker. 