# Implicit conversions between type aliases **URL:** \ **Category:** Language Design\ **Created:** [June 10, 2017, 12:52pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222 "2017-06-10T12:52:12Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![0xmarcin](https://avatars.discourse-cdn.com/v4/letter/0/6f9a4e/32.png) [@0xmarcin](https://discuss.kotlinlang.org/u/0xmarcin)\ **Post date:** [June 10, 2017, 12:52pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/1 "2017-06-10T12:52:12Z")
How it comes that Kotlin allows implicit conversions between type aliases. For example: ```kotlin typealias A1 = (Int) -> Int typealias A2 = (Int) -> Int fun main(args: Array) { val f1: A1 = { it } val f2: A2 = f1 } ``` compiles without a warning, but from programmer point of view `A1` and `A2` are distinct types. On the other hand I cannot assign `Int` to `Long` variable: ```kotlin val i1: Int = 1 val i2: Long = i1 // error ``` I appreciate Kotlin type safety and I would like it to also extend on type aliases. I guess current behavior is inconsistent with the rest of the language. Am I wrong? ---
**Author:** ![Jonathan.Haas](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@Jonathan.Haas](https://discuss.kotlinlang.org/u/Jonathan.Haas)\ **Post date:** [June 10, 2017, 1:57pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/2 "2017-06-10T13:57:56Z")
Aliases are just aliases, they’re the same type so they’re assignable. Int and Long are different types, so they need a conversion. ---
**Author:** ![mfursov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/mfursov/32/1460_2.png) [@mfursov](https://discuss.kotlinlang.org/u/mfursov)\ **Post date:** [July 26, 2017, 1:51pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/3 "2017-07-26T13:51:01Z")
This implicit conversion becomes very useful when it comes to anonymous (lambda) functions. But I agree with the original author that the problem exits: why we have type safety when we cast interfaces/classes but not for functions? May be there should be/is additional syntax I’m missing? Here is an example that shows that type safety is important for classes/interfaces in Kotlin even for «compatible» types: ``` class C1(x: Int) class C2(x: Int) fun fooC1(): C1? = null fun fooC2(): C2? = null object O1 {val x: Int = 1} object O2 {val x: Int = 2} fun fooO1(): O1? = null fun fooO2(): O2? = null interface I1 interface I2 fun fooI1(): I1? = null fun fooI2(): I2? = null fun x() { val c1: C1? = fooC1() val c2: C2? = fooC1() // Type error! val o1: O1? = fooO1() val o2: O2? = fooO1() // Type error! val i1: I1? = fooI1() val i2: I2? = fooI1() // Type error! } ``` Is there any way to reach the same level of type safety for a top level function declaration? ---
**Author:** ![Jonathan.Haas](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@Jonathan.Haas](https://discuss.kotlinlang.org/u/Jonathan.Haas)\ **Post date:** [July 26, 2017, 2:06pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/4 "2017-07-26T14:06:31Z")
> [@mfursov](#): > > Is there any way to reach the same level of type safety for a top level function declaration? There is the same level of type safety. It’s just that (Int) → Int is the same type as (Int) → Int so obviously it’s assignable. In your example code you don’t use type aliases. If you’d have used them, they would’ve been assignable again. You’re missing the problem. What you don’t like is the behavior of type aliases, not the behavior of function declarations. ---
**Author:** ![mfursov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/mfursov/32/1460_2.png) [@mfursov](https://discuss.kotlinlang.org/u/mfursov)\ **Post date:** [July 26, 2017, 2:34pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/5 "2017-07-26T14:34:11Z")
> [@Jonathan.Haas](#): > > You’re missing the problem. What you don’t like is the behavior of type aliases, not the behavior of function declarations. This is not true. I like behavior of type aliases in they current form. The goal of my post was to emphasize that there is a disbalance in the language how strong types are supported for classes/objects/interfaces and functions. First have more fine grained type support. I do not know how to solve this problem (introduce **funtype** 🙂 ?) but for a lot of people when they start to use typealiases for functions it becomes a valid question: what is the way to make function conversion explicit? So _getOranges_ will not be occasionally used in the place where _getApples_ is expected. ---
**Author:** ![Jonathan.Haas](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@Jonathan.Haas](https://discuss.kotlinlang.org/u/Jonathan.Haas)\ **Post date:** [July 27, 2017, 8:41am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/6 "2017-07-27T08:41:27Z")
> [@mfursov](#): > > The goal of my post was to emphasize that there is a disbalance in the language how strong types are supported for classes/objects/interfaces and functions. First have more fine grained type support. Int is the same as Int and typealiasing Int to Money and to Weight won’t prevent you from assigning Money to Weight. (Int) → Int is the same as (Int) → Int and typealiasing it to A1 and to A2 won’t prevent you from assigning A1 to A2. There is absolutely no difference here. It looks like you either want to subclass function types or have something like SAM classes supported. ---
**Author:** ![elizarov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/elizarov/32/2164_2.png) [@elizarov](https://discuss.kotlinlang.org/u/elizarov)\ **Post date:** [July 28, 2017, 4:05pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/7 "2017-07-28T16:05:39Z")
You should vote for SAM support in Kotlin: [https://youtrack.jetbrains.com/issue/KT-7770](https://youtrack.jetbrains.com/issue/KT-7770) SAM is exactly the “funtype” you are looking for. ---
**Author:** ![clubin](https://avatars.discourse-cdn.com/v4/letter/c/5daacb/32.png) [@clubin](https://discuss.kotlinlang.org/u/clubin)\ **Post date:** [July 29, 2017, 12:08pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/8 "2017-07-29T12:08:03Z")
The traditional name for the feature you expected typealias to be is a “typedef”. An “alias”, or in this case a “typealias”, works just as the English word does – that is, to the compiler the typealias will actually be the same thing simply called by another name (like a nickname). (Any issue tracker for a typedef feature open?) (PS. Actually I’m lying a bit above… Unfortunately the Kotlin compiler doesn’t always support typealiases properly, meaning it isn’t exactly the same thing as writing out the aliased type ☹ ) ---
**Author:** ![clubin](https://avatars.discourse-cdn.com/v4/letter/c/5daacb/32.png) [@clubin](https://discuss.kotlinlang.org/u/clubin)\ **Post date:** [July 29, 2017, 12:26pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/9 "2017-07-29T12:26:18Z")
> [@clubin](#): > > (Any issue tracker for a typedef feature open?) Issue tracker _or_ KEEP _or_ official statement/plan ---
**Author:** ![alanfo](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@alanfo](https://discuss.kotlinlang.org/u/alanfo)\ **Post date:** [July 29, 2017, 4:55pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/10 "2017-07-29T16:55:28Z")
Although less general than ‘typedefs’, it was mentioned in the recent survey of possible future features that ‘inline or value classes’ could be used to represent units of measurement, custom strings or dates and even unsigned integers (see item 9 in [this list](https://drive.google.com/file/d/0BwAovUlww0CmVmNQTXd4TTdKYUU/view)). As such, they would be distinct from their underlying types without the need for a wrapper object and could have their own properties or methods. Moreover, as long as this was limited to a single immutable data field, it could be implemented without waiting for value types to be added to Java which is probably several years down the track, if indeed they are ever added at all. It’s a feature which I personally would love to see as we could do quite a lot with it and was the fifth most popular (out of 20) with only a few people against. Its prospects look good because Kotlin Native needs unsigned types for a good C interop story and I doubt whether JB would want to restrict new language features to a single target. ---
**Author:** ![elizarov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/elizarov/32/2164_2.png) [@elizarov](https://discuss.kotlinlang.org/u/elizarov)\ **Post date:** [July 30, 2017, 4:48pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/11 "2017-07-30T16:48:20Z")
I’m curious as to why you think that inline classes are less general than typedefs? I was under impression that reverse is true (that is, inline classes are strictly more powerful than typedefs). ---
**Author:** ![alanfo](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@alanfo](https://discuss.kotlinlang.org/u/alanfo)\ **Post date:** [July 31, 2017, 12:00am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/12 "2017-07-31T00:00:46Z")
I meant less general in scope. Some languages (Nim for example) allow you to create distinct types from any other base type no matter how many fields it has. If I’ve understood it correctly, under the ‘inline or value class’ proposal you’ll only be able to create a distinct type with a single immutable data field though you’ll then be able to split this up into smaller types and expose those as properties. Incidentally, although I think that when @clubin referred to ‘typedefs’ he was talking about distinct types, in the only languages I know (C/C++) where that word is actually used it is, of course, a misnomer. Apart from some minor differences, a typedef is just a type alias (not a type definition) and so, yes, the proposal is more powerful than that. ---
**Author:** ![elizarov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/elizarov/32/2164_2.png) [@elizarov](https://discuss.kotlinlang.org/u/elizarov)\ **Post date:** [July 31, 2017, 4:28pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/13 "2017-07-31T16:28:58Z")
Disclaimer: we have not committed yet to add any kind of inline classes to Kotlin, so everything I write below is purely hypothetical. However, Kotlin’s inline clases are designed provide exactly the same features that Nim’s `distinct` type provides. Nim’s definition of ```auto type Dollar = distinct int ``` is semantically equivalent to Kotlin’s: ```auto inline class Dollar(val amount: Int) ``` In both cases there is no limit on what other type (beyond `Int`) can be used as a base on which this new type is defined. P.S. In projects where performance is not of a paramount importance you can _already_ get the functionality of `distinct` type in Kotlin just by writing as in the example above, but without `inline` modifier. ---
**Author:** ![alanfo](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@alanfo](https://discuss.kotlinlang.org/u/alanfo)\ **Post date:** [July 31, 2017, 8:49pm UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/14 "2017-07-31T20:49:26Z")
@Elizarov, thanks for clarifying how the inline class proposal is intended to work. I won’t get too excited in case it isn’t implemented but I’m hopeful 🙂 ---
**Author:** ![clubin](https://avatars.discourse-cdn.com/v4/letter/c/5daacb/32.png) [@clubin](https://discuss.kotlinlang.org/u/clubin)\ **Post date:** [August 6, 2017, 9:50am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/15 "2017-08-06T09:50:42Z")
> [@alanfo](#): > > Incidentally, although I think that when @clubin referred to ‘typedefs’ he was talking about distinct types, in the only languages I know (C/C++) where that word is actually used it is, of course, a misnomer. Apart from some minor differences, a typedef is just a type alias (not a type definition) and so, yes, the proposal is more powerful than that. Ah, but in the wondrous language I’m currently involved with that I won’t mention in this forum at the moment, the `typedef`s are appropriately strong, indeed creating type-system differentiable types… 🤩 Thanks for the reminder about C++'s particularly weak typedef implementation, though, as it seems that I’ve been [mostly] uninvolved with C++ long enough that I’m finally starting to forget some of the smaller details of exactly how it handled some things… ---
**Author:** ![kotlinikov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/kotlinikov/32/4170_2.png) [@kotlinikov](https://discuss.kotlinlang.org/u/kotlinikov)\ **Post date:** [September 6, 2017, 10:25am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/16 "2017-09-06T10:25:19Z")
Hypothetically speaking, of course, how would an inline class be represented to the Java side? I would like to write something like this in Kotlin: ``` inline class Millis(val amount: Long) @WorkerThread fun isTimeToEat(db: DatabaseHandle, nowMs: Millis): Boolean { … val someLongAsSeconds = db.getMeSomeRawLongsPlease() // Can't write this due to 'distinct' types! // return nowMs > someLongAsSeconds return Long(nowMs) / 1_000 > someLongAsSeconds } ``` Would the Java side see a new `Millis` type or just the plain old `Long` (or `long`)? I’m very interested in this feature, since another useful thing I could do is mark the longs coming from the database as _distinct_ primary key values to avoid mixing them. ---
**Author:** ![fvasco](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fvasco/32/1961_2.png) [@fvasco](https://discuss.kotlinlang.org/u/fvasco)\ **Post date:** [September 6, 2017, 11:02am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/17 "2017-09-06T11:02:50Z")
Feature 9 [https://drive.google.com/file/d/0BwAovUlww0CmVmNQTXd4TTdKYUU/view](https://drive.google.com/file/d/0BwAovUlww0CmVmNQTXd4TTdKYUU/view) ---
**Author:** ![Oliver\_Plohmann](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/oliver_plohmann/32/2398_2.png) [@Oliver\_Plohmann](https://discuss.kotlinlang.org/u/Oliver_Plohmann)\ **Post date:** [September 8, 2017, 7:07am UTC](https://discuss.kotlinlang.org/t/implicit-conversions-between-type-aliases/3222/18 "2017-09-08T07:07:08Z")
Maybe some approach making use of delegates can get something accomplished that is close to what typedefs are, e.g. methods have different signatures and therefore require parameters of different types, but inside those methods the declared different types in the signature do not matter as delegates just forward calls to the “original”.