Nos complace anunciar la versión Kotlin 1.2 beta. Con esta versión, desvelamos
la característica más relevante de Kotlin 1.2: soporte experimental para proyectos multiplataforma.
También, consideramos ya completa la librería estándar y del lenguaje de la 1.2.
Y ya hemos implementado todas las características planeadas para Kotlin 1.2.
Ahora es el momento ideal para que nos déis vuestra opinión sobre los cambios – todavía
tenemos tiempo para tener en cuenta vuestros comentarios y ajustar el diseño
de la versión final de la 1.2 si es necesario.

En relación a las herramientas, la beta de Kotlin 1.2, incluye el mismo conjunto
de características que se han liberado recientemente en la actualización 1.1.50.
La beta es compatible con todas las versiones de IntelliJ IDEA desde la 2016.3
gasta la 2017.3, así como Android Studio 2.3 y 3.0.

La lista de cambios completa desde la 1.2-M2 se puede encontrar aquí, con las
cosas más destacadas en la parte siguiente del artículo.

Proyectos multiplataforma

Los proyectos multiplataforma son una característica experimental en Kotlin 1.2,
permitiendo reusar código entre plataformas destino soportadas por Kotlin – JVM,
JavaScript y (en el futuro) Nativo. En un proyecto multiplataforma, pones código
que se comparte entre plataformas en un módulo común, y las partes específicas
de cada plataforma en módulos específicos de cada plataforma que dependen de él.
Cuando compilas dichos proyectos para la plataforma específica, el código de
ambos, el común y las partes específicas de plataforma, se genera.

Una característica clave del soporte de los proyectos multiplataforma es la
posibilidad de expresar las dependencias de código común en partes específicas de
plataforma a través de declaraciones <code class="highlighter-rouge">expected y <code class="highlighter-rouge">actual. Una declaración
<code class="highlighter-rouge">expected especifica un API (clase, interfaz, anotación, declaración global, etc.).
Una declaración <code class="highlighter-rouge">actual es o bien una implementación específica por plataforma
del API o un alias de tipo (typealias) redireccionando a una implementación
existente del API en una librería externa:

`// Common code

expectfunhello(world:String)



expectclassURL(spec:String){

openfungetHost():String

openfungetPath():String

}



// JVM code

actualfunhello(world:String){

println("Hello JVM $world")

}



actualtypealiasURL=java.net.URL`
Para más información, echad un vistazo a la [documentación de los proyectos multiplataforma](http://kotlinlang.org/docs/reference/multiplatform.html).

Si ya habéis probado esta característica antes de que se anunciase, por favor,
tened en cuenta que tenéis que actualizar vuestros proyectos: los keywords
<code class="highlighter-rouge">header y <code class="highlighter-rouge">impl se han renombrado a <code class="highlighter-rouge">expect y <code class="highlighter-rouge">actual. Para actualizar
vuestro código automáticamente usad <code class="highlighter-rouge">Analyze | Cleanup Code... en IntelliJ IDEA.

Lenguaje y compilador

Literales de array en anotaciones

Una nueva característica del lenguaje en Kotlin 1.2 es el soporte de literales de
array en anotaciones
. Ahora, en vez de escribir algo como
<code class="highlighter-rouge">@CacheConfig(cacheNames = arrayOf("books", "default")) podéis simplemente usar una expresión literal:

`@CacheConfig(cacheNames=["books","default"])`
Dicha característica ya estaba disponible en el hito anterior de Kotlin 1.2. En la beta 1.2, hemos hecho la sintaxis más consistente y permitimos usar los literales de array tanto en arrays como en parámetros vararg:
`@RequestMapping(value=["value1","value2"],path=["path1","path2"])`
Para habilitar dicho cambio, hemos decidido hacer ciertos ajustes a la sintaxis para usar argumentos con nombre junto a `vararg`, tanto en llamadas a métodos normales como en anotaciones. Puede que os sorprenda, pero en Kotlin 1.1, cuando llamábamos a métodos vararg usando la sintaxis de argumentos con nombre, era posible pasar un solo argumento como un valor inmediato:
`funfoo(varargstrs:String){...}



foo(strs="abc")`
Decir que a strs se le pasa una cadena `"abc"` parece algo poco intuitivo, y también nos obliga a usar el operador de propagación cuando pasamos un array entero como un argumento con nombre:
``` foo(strs = *arr) ```
Nos encantaría permitir `foo(strs = arr)`, pero por compatibilidad, requiere una migración progresiva, así que en la 1.2 hemos deprecado `foo(strs = "abc")` y como reemplazo (en el caso poco probable de que hayáis usado esta sintaxis), podéis usar el operador de propagación y el método arrayOf:
``` foo(x = *arrayOf("abc")) ```
Tenemos planeado implementar una [optimización en el compilador](https://youtrack.jetbrains.com/issue/KT-20462) para evitar la reserva del array y su correspondiente copia en dichas llamadas.

Como las anotaciones están en un ámbito mucho más restringido, nos podemos saltar un
paso en la migración, asó que podéis usar los literales de array sin usar el operador
de propagación:

``` annotation class Foo(vararg value: String)

@Foo(value = "a") // deprecated
@Foo(value = ["a"]) // correct


</div></div>Echad un ojo a esta [entrada en TouTrack](https://youtrack.jetbrains.com/issue/KT-20171) para más información.

#### Mejoras en lateinit

Hemos añadido una nueva API de reflexión para permitir comprobar si una variable  
`<code class="highlighter-rouge">lateinit` ha sido inicializada.

<div class="highlighter-rouge"><div class="highlight">```
lateinit var file: File

// ...

if (::file.isInitialized) {
  ...
}
Esto es una implementación parcial de la [propuesta de este KEEP](https://github.com/Kotlin/KEEP/pull/73/files); la parte restante (el método de desinicialización) se ha pospuesto, y posiblemente se implemente en la 1.3.

A partir de ahora también se puede usar el modificador <code class="highlighter-rouge">lateinit tanto en declaraciones globales, como en variables locales. Donde la última se puede usar, por ejemplo,
al inicializar un grafo de objetos en el que hay una dependencia circular entre
las propiedades de los objetos y el grafo. Ejemplo:

``` fun test() { lateinit var x: Component

// inject takes a lambda which must return the Component though
val injector = inject(
...,
componentProvider = { x },
...
)

// Initialization is only possible via injector, once it has been run
x = injector.createComponent()
}


</div></div>Echad un ojo al [KEEP](https://github.com/Kotlin/KEEP/blob/master/proposals/local-and-top-level-lateinit-vars.md) para obtener más información.

### Mejoras en las referencias llamables vinculadas *Bound callable reference*

Ahora podéis omitir `<code class="highlighter-rouge">this` en las expresiones somo `<code class="highlighter-rouge">this::foo`, para crear  
 referencias llamables vinculadas. En su lugar, podéis escribir simplemente `<code class="highlighter-rouge">::foo`.  
 Anteriormente la sintaxis con la parte izquierda vacía únicamente se podía usar  
 para crear referencias llamables en declaraciones globales.  
 Para más información, echado un ojo a esta [entrada en YouTrack](https://youtrack.jetbrains.com/issue/KT-15667).

#### Mejoras de inferencia de tipos

Ahora el compilador de Kotlin puede usar la información del casteo de tipos para  
 realizar la inferencia de tipos. Si llamáis a un método genérico que devuelve un  
 parámetro de tipo T y casteais el valor de retorno a un tipo específico Foo, el  
 compilador ahora entiende que T para esta llamada tiene que estar vinculada al  
 tipo Foo. Esto es particularmente importante para los desarrolladores Android porque  
 el compilador puede analizar correctamente las llamadas a `<code class="highlighter-rouge">findViewById` en  
 el nivel de API de android 26:

`<code class="highlighter-rouge">val button = findViewById(R.id.button) as Button`

Como el método se ha cambiado a `<code class="highlighter-rouge"><T extends View> T findViewById(int id)` en  
 Kotlin 1.1 no se podía inferir el tipo del argumento `<code class="highlighter-rouge">T` en dichas llamadas.  
 Para más información, echad un ojo a esta [entrada de YouTrack](https://youtrack.jetbrains.com/issue/KT-13644).

### Advertencias como errores

El compilador ahora proporciona una opción para tratar todas las advertencias como errores. Usad `<code class="highlighter-rouge">-Werror` en la línea de comandos, o el siguiente snippet de Gradle:

<figure class="highlight">`<code class="language-kotlin" data-lang="kotlin"><span class="n">compileKotlin</span><span class="p">{</span><br data-jekyll-commonmark-ghpages=""></br><span class="n">kotlinOptions</span><span class="p">.</span><span class="n">warningsAsErrors</span><span class="p">=</span><span class="k">true</span><br data-jekyll-commonmark-ghpages=""></br><span class="p">}</span>`

</figure>### Mejoras en los smart cast

Los smart casts ahora se aplican a los [sujetos de los casteos seguros](https://youtrack.jetbrains.com/issue/KT-4565):

<div class="highlighter-rouge"><div class="highlight">```
fun foo(x: Foo?) {
  val b = (x as? SubClass)?.subclassMethod1()
  if (b != null) {
    x.subclassMethod2() // x is smart cast to SubClass
  }
}
Ahora también [se permiten](https://youtrack.jetbrains.com/issue/KT-14486) los smart casts en lambdas para variables var que se modifican únicamente antes de la lambda:
``` var x: String? = null if (flag) x = "Yahoo!"

run {
if (x != null) {
println(x.length) // x is smart cast to String
}
}


</div></div>### Clases anidadas en entradas de enum

Hemos [deprecado](https://youtrack.jetbrains.com/issue/KT-16310) las clases anidadas dentro de entradas de enums; y como corrección, debéis marcar las clases como inner.


## Librería estándar

Compatibilidad con la separación de paquetes

La librería estándar de Kotlin es ahora completamente compatible con el sistema  
 de módulos de Java 9, que prohibe separar paquetes (multiple archivos jar declarando  
 clases en el mismo paquete). Para soportar eso, hemos creado nuevos artefactos  
`<code class="highlighter-rouge">kotlin-stdlib-jdk7` y `<code class="highlighter-rouge">kotlin-stdlib-jdk8`, que reemplazan los viejos `<code class="highlighter-rouge">kotlin-stdlib-jre7`  
 y `<code class="highlighter-rouge">kotlin-stdlib-jre8`. Las declaraciones en el nuevo artefacto son visibles bajo los  
 mismos nombres de paquete desde el punto de vista de Kotlin, pero, debido a cierta  
 magia del compilador que hemos añadido, son visibles desde diferentes nombres de paquete  
 desde Java. De forma que, cambiar a los nuevos artefactos no os supondrá ningún  
 cambio en vuestro código.

Otro cambio que hemos hecho para cercionarnos de la compatibilidad con el nuevo  
 sistema de módulos es quitar las declaraciones deprecadas del paquete `<code class="highlighter-rouge">kotlin.reflect`  
 de la librería `<code class="highlighter-rouge">kotlin-reflect`. Si los estábais usando, tendréis que hacer el cambio  
 a las declaraciones en el paquete `<code class="highlighter-rouge">kotlin.reflect.full`, que está disponible desde Kotlin 1.1.

### kotlin.math

`<code class="highlighter-rouge">kotlin.math` es un nuevo paquete de la librería estándar de Kotlin 1.2, que permite realizar operaciones matemáticas en el código multiplataforma. En la 1.2-Beta, hemos hecho varias mejoras :

- Incluimos las funciones hiperbólicas (`<code class="highlighter-rouge">asinh`, `<code class="highlighter-rouge">acosh`, `<code class="highlighter-rouge">atanh`)
- Hemos añadido las funciones relacionadas con la representación binaria de los números en coma flotante (toBits, nextUp y demás), también a JavaScript
- Mejoras mejorado la precisión de los polyfills de matemáticas en JavaScript

### Notas de versiones preeliminares

Como en otras versiones hito, no damos ningún tipo de garantía de compatibilidad para las características nuevas del lenguaje o de las librerías.  
 Cualquier cosa introducida en las versiones preeliminares de la 1.2 está **sujeta a cambio** antes de la versión final de la 1.2. Cuando alcancemos la versión final, los binarios producidos por versiones preeliminares  
 serán rechazadas por el compilador: lo que os obligará a recompilar todo lo que se había compilado  
 en las 1.2‑Mx o 1.2-Beta.  
 Sin embargo, todo el código compilado por las versiones 1.1.x o anteriores es perfectamente válido  
 sin necesidad de recompilar.

### Cómo probarlo

**En Maven/Gradle:** Añadid `<code class="highlighter-rouge">http://dl.bintray.com/kotlin/kotlin-eap-1.2` como repositorio en vuestros build script y vuestros proyectos; usad `<code class="highlighter-rouge">1.2.0-beta-31` como número de versión para el plugin del compilador y la librería estándar.

**En IntelliJ IDEA:** Id a `<code class="highlighter-rouge">Tools → Kotlin → Configure Kotlin Plugin Updates`, y seleccionad `<code class="highlighter-rouge">“Early Access Preview 1.2”` en el desplegable de `<code class="highlighter-rouge">Update channel`, y pulsad `<code class="highlighter-rouge">Check for updates`.  
 El compilador de la línea de comandos se puede descargar [la página de *release* de GitHub](https://github.com/JetBrains/kotlin/releases/tag/v1.2-beta).

**En try.kotlinlang.org:** Usad el desplegable de la esquina inferior derecha para cambiar el compilador a la versión 1.2‑Beta (próximamente).