On Sun, Jun 28, 2020 at 2:56 PM <zhouhaibing...@gmail.com> wrote:
> After looking at the latest proposal - 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md,
>  and also checked a curated list of discussion at - 
> https://groups.google.com/forum/#!msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ.
> However, I do find myself still interested in a case like below:
> type foo struct{}
> func bar(x int) func(int) int {
>     return func(y int) int {
>         return x + y
>     }
> }
> func main() {
>     foo := 1
>     result := bar(foo)(2)
>     fmt.Println(result)
> }
> I believe a function which returns another function in current Go world is 
> pretty normal. I specifically mocked an example above - where the first 
> parameter name appears to collide with a type name.
> With that said, I guess compiler won't have any issues to figure it out when 
> it is type parameter and when it is not. However, I think that's not trivial 
> for a human, though.
> So is this a problem or I may just have ignored anything?

There are many ways to write ambiguous code in Go, or in any
programming language.  The interesting question here is not "can it be
ambiguous?"  It is "will it be ambiguous in practice?"  That is why I
am encouraging people to write real code using the design draft, so
that we can see how that real code looks.

In particular, the ambiguity in your example hinges on a collision
between a variable name and a type name.  In Go, for better or for
worse, variable names and type names live in the same namespace and
can shadow each other.  Yet people are rarely confused by this in
practice.  Real code rarely uses identifiers like "foo".  In real
code, when we look at an identifier, how often are we confused as to
whether that identifier is a variable, a function, a type, or a
constant?  And how often do those confusing cases collide with a case
like a function that returns a function that is immediately called?

I can guess answers to those questions, but I don't know.  The only
way to know is to look at real code.



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 

Reply via email to