IMHO << should only be used for bit shifting

but for bit shifting it should be used

if we introduce the operator into the language, then we also have to let the users overload it, and then they will use it for all sorts of purposes that have nothing to do with bit shifting

Well, that's true. But that's also true for any operator you're allowing overload on.

and bit shifting comes up rare enough that there’s rather little difference between expressing it as << and as shl

yes. that’s why the number of operators that can be overloaded in Kotlin is very limited.

I've seen a lot of operators very badly overloaded.

Does anyone know the reason behind why extension methods in the collections lib do not check for subtypes?

like there is an overloaded version for List and Iterable, but the Iterable does not check whether the parameter is a List

in that case it could forward the call to the List variant

@david: there are, but may be some specific functions are missing this optimization. What particular function do you mean?

@orangy: say firstOrNull

fwiw:

++

,

++:

,

+:

,

/:

,

+:

,

::

,

:::

and

:\

are operators that are defined in some other popular jvm language for its

List

class. This seems what is to happen when more and more operators are allowed in a language. I therefor think the choice of the Kotlin team to restrict operators as much as possible is a good thing.

@mplatvoet: scala’s choice about those operators was based on other functional languages, such as erlang and haskell that use the same operators in the same manner

I understand it''s origin and reasoning, I just don't agree with it 😉

@frankdavid: The price of reification is that interop is extremely difficult, especially with statically typed languages and even more so when such languages have generics

@frankdavid: The fact that C# supports reification is the main reason why Scala.net stopped being maintained: they just couldn't get the Scala generics to work on .net

@cedric: so you’re saying the main difficulty that arises with reification is that it is hard to create other languages for the same VM?

Yup

There are other costs too but that's the main one

But as a user of C#, why would I care?

cool

@cfleming: @mark.howard @cedric ....

"true".toBoolean()

you have to scroll back a bit to see what that is about.

@yole: any schedule plans for 1.0 release?

he will say "no, we don't announce such dates"

search here for "1.0 release" and you'll find a few answers already

I'd say "soon" is a reasonable answer

why is int not implicitly converted to long?

what could go wrong with this?