On Sun, Jul 5, 2020 at 12:22 PM, Jake Montgomery <jake6...@gmail.com> wrote:
> I understand Ian's position of wait and see. But for completeness, I will > point out that this new 'ambiguity' is different from the current cases > where there would be a "collision > between a variable name and a type name." As far as I can tell, any such > collision in Go 1 would fail to compile. However, with the current > parentheses based generics, such collisions could end up compiling, or > failing to compile at a later location in a confusing way: > In an expression x(y)(z), x could be already be a type or a value and successfully compile only to have unexpected results later on if there was any confusion about what x refers to. What's changing is that y could also now be a type or a value. https://play.golang.org/p/jtxrrop7gP7 Ultimately, these kinds of examples are contrived. They're relying on shadowing unexported identifiers with meaningless names in your own code, and using the same name for a type vs. a value. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANjmGJvScUn5Uv5G66swrwwH_Y0diyNQ4-zMZcbRZjeQNqSOJw%40mail.gmail.com.
