go - for - ¿Cuál es la diferencia entre "<-chan" y "chan" como un tipo de devolución de función?
golang select (2)
Golang novato aquí.
¿Hay una diferencia funcional entre
func randomNumberGenerator() <-chan int {
y
func randomNumberGenerator() chan int {
Intenté usar ambos y parecen funcionar bien para mí.
He visto el primero utilizado por Rob Pike (uno de los creadores de Go) en su charla Go Concurrency Patterns en Google IO 2012. También lo he visto utilizado en el sitio web oficial de Go. ¿Por qué agregar 2 caracteres adicionales ("<-") cuando puede omitirlo? Intenté buscar la diferencia en la web, pero no pude encontrarla.
Ambos funcionarán de hecho. Pero uno será más restrictivo. La forma con la flecha apuntando lejos de la palabra clave chan significa que el canal devuelto solo podrá ser extraído por el código del cliente. No se permite empujar: el empuje se realizará mediante la función de generador de números aleatorios. Por el contrario, hay una tercera forma con la flecha apuntando hacia chan , que hace que dicho canal sea solo de escritura para los clientes.
chan // read-write
<-chan // read only
chan<- // write only
Estas restricciones adicionales pueden mejorar la expresión de intención y ajustar el sistema de tipos: los intentos de forzar cosas en un canal de solo lectura le dejarán con un error de compilación, y también intentará leer desde un canal de solo escritura. Estas restricciones se pueden expresar en el tipo de devolución, pero también pueden ser parte de la firma del parámetro. Como en :
func log(<-chan string) { ...
Allí puede saber, solo con la firma, que la función de log consumirá datos del canal y no le enviará ninguno.
Este es un ejemplo de un canal de solo recepción .
El operador opcional
<-especifica la dirección del canal, enviar o recibir. Si no se da ninguna dirección, el canal es bidireccional. Un canal puede estar limitado solo para enviar o solo para recibir por conversión o asignación.
Es útil decirle a los usuarios de su API que solo deberían recibir de ese canal y nunca enviar, de lo contrario, suceden cosas malas. Se considera una buena práctica especificar la dirección de sus canales en las API públicas. Ver también: Principios de diseño de Go API con canales .