Hi, TypeScript uses the same convention to descri...

# announcements

[Paulius Ruminas]

Hi,

TypeScript uses the same convention to describe constraints for generic types for both classes and functions e.g. function foo<T extends Bar>() {} and class Foo<T extends Bar> {}. Just out of curiosity were there any limitations why it couldn't be like fun foo<T : Bar>() {} in Kotlin?

[Ruckus]

fun <T : Bar> foo<T>() {}

isn't valid Kotlin. Did you mean:

fun <T : Bar> foo() {}

[Paulius Ruminas]

Yes

[Paulius Ruminas]

Classes are described like class Foo<T : Bar> so I'm wondering why functions do not follow the same convention.

[Ruckus]

I don't think your suggestion is any more "natural" looking. It may be more familiar to you, but not intrinsically natural. The seeming disagreement between class and function definitions is a much more valid question.

[Ruckus]

(Also, your "needs less typing argument" doesn't make sense, as it's the exact same thing in a different spot)

[Paulius Ruminas]

Yes the main reason I'm asking is why they do not follow the same convention as classes or vice versa.

[Ruckus]

With your edits, I now look like a crazy guy complaining about stuff that isn't there 😆

[Paulius Ruminas]

I wanted to make it more clear as you pointed out a lot of mistakes in the question. Sorry 😄

[Ruckus]

I only meant it looks funny reading through it now. The edits were definitely good and hopefully get you a good answer.

[Dico]

I was wondering this some time back, forgot what the answer was..

[karelpeeters]

I remember reading a Kotlin discussions thread about this a while ago, and I think the explanation was the receiver type:
fun T.foo<T>() is weird. The same reason works for Java with the return type: public T foo<T>() would be weird.

[karelpeeters]

"weird" as in "a type is used before it is declared"

[Paulius Ruminas]

I think the explanation was the receiver type: fun T.foo<T>() is weird.

probably this is why they chose the current syntax.