Re: [go-nuts] [generic] Readibility of Multiple Parenthsis
On Sun, Jul 5, 2020 at 12:22 PM, Jake Montgomery 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.
Re: [go-nuts] [generic] Readibility of Multiple Parenthsis
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:
https://go2goplay.golang.org/p/nufvRIolhmF
package main
import "fmt"
type foo int
type Intish interface {
type int
}
func bar(type T Intish)(x T) func(T) T {
return func(y T) T {
return x + y
}
}
func one() {
foo := 1
result := bar(foo)(2)
fmt.Printf("%T\n", result)
}
func two() {
result := bar(foo)(2)
fmt.Printf("%T\n", result)
}
func main() {
one()
two()
}
Output:
int
func(main.foo) main.foo
The first set a parens after bar can reasonably be either a type or a
value. Whether this will actually lead to confuision or not only experince
will tell (as Ian keeps saying.)
(OT, but I am one of those folks who is suffering from parenthesis fatigue,
and wish there were some more clear way to denote a type when using a
generic.)
On Sunday, June 28, 2020 at 6:29:08 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Jun 28, 2020 at 2:56 PM >
> 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.
>
> Thanks.
>
> Ian
>
--
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/d8a6436f-6f0c-441c--f060b714cb6do%40googlegroups.com.
Re: [go-nuts] [generic] Readibility of Multiple Parenthsis
On Sun, Jun 28, 2020 at 2:56 PM 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.
Thanks.
Ian
--
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/CAOyqgcX6Bo_fR%3D%3DDSFOKDUjEw%2B%3Drvy2OT5Ut-7%3D25fVuyqeNjA%40mail.gmail.com.
