This is done primarily for JVM interoperability, otherwise it's impossible to
inherit from CharSequence there. On JS subSequence at the moment just invokes
substring.
#KT-5956 Fixed
This is done for JVM interoperability. There's still a member function
String.get() and an extension function "get" on CharSequence
#KT-1730 Fixed
#KT-5389 Fixed
And String.length as well.
This is done for JVM interoperability: java.lang.CharSequence is an open class
and has a function 'length()' which should be implemented in subclasses
somehow.
A minor unexpected effect of this is that String.length() is now a compile-time
constant (it wasn't such as a property because properties are not supported in
compile-time constant evaluation)
#KT-3571 Fixed
This is not something that needs to be intrinsified. Note that compiler
optimizations are still possible and the fact whether 'indices' is a member or
an extension is irrelevant to the optimizer
- Cloneable is a trait with a single protected member 'clone', which is mapped
to java.lang.Cloneable on JVM
- 'clone' is non-abstract to be able to call 'super.clone()' in the
implementations. Also if you need your class to be Cloneable, most of the
time inheriting from Cloneable and calling 'super.clone()' will work
- hack 'super.clone()' in JVM intrinsics and TImpl delegation generation
- make arrays Cloneable, handle 'clone()' calls in the intrinsic
#KT-4890 Fixed
Float.rangeTo(Long) and Long.rangeTo(Float) now both return FloatRange for
consistency with other binary operations between floats and longs which, in
turn, return float to be consistent with Java
BuiltInsSerializer now serializes built-ins found in two source roots:
core/builtins/native and core/builtins/src
Add return types to some declarations in core/builtins/src, because now that
BuiltInsSerializer processes them, it launches lazy resolution which can't
always deduce the return type
Pavel V. Talanov