Extension Functions on Type Aliases Should only Be Accessable From Similar Types

Language Design
1

I’ve been playing around with Kotlin 1.1 and noticed something odd with type aliases.

fun main(args: Array<String>) {
	val foo: Foo = 1L
	
	foo.bar()
}


typealias Foo = Long

internal fun Foo.foo() {
	
}

typealias Bar = Long

internal fun Bar.bar() {
	
}

The .bar() method is callable from typealias Foo even though .bar() is an extension function on the typealias Bar?

It would be nice to have some type of object oriented hierarchy on TypeAliases even though that might not have been their initial intent.

1 Like
2

A type alias does not create a new type, it just assigns an alternative name to an existing type. A feature to create new types has been proposed, but if it ever gets implemented (which may not be easy to do due to Java interop requirements), it will use a different keyword, because it will have different semantics.

3

Any news on the feature . Any idea on which release it is going to get implemented ?

4

Check out this recent thread and in particular what @elizarov said towards the end.

5

I think, even if it’s a shallow layer (still fine at runtime), allowing something like this in such a way that the compiler can enforce API restrictions for you would be extremely useful.

An example of what I mean - https://twitter.com/pandanomic/status/908592367401349120

1 Like
6

I would also find some shallow layer helpful. I’ve defined type aliases for Long and String and extension functions which are starting to pollute Intellij’s autocomplete. If something could be done just in the IDE to hide extension function on type alias from the instances of the existing type that would be great

7

Inline classes solve this problem. Safe to mark it as supported :slight_smile: