On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Nov 8, 2019 at 11:40 AM André Eriksson <ean...@gmail.com
> <javascript:>> wrote:
> >
> > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
> >>
> >> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson <ean...@gmail.com>
> wrote:
> >> >
> >> > Interesting. Do you have a reference to where that happens?
> >>
> >> The method (*Package).rewriteCall in cmd/cgo/gcc.go. But more useful
> >> might be to experiment with some cgo code and build with `go build
> >> -work` and look in the $WORK directory to see the generated files.
> >>
> >>
> >> > If i understand you correctly, however, it doesn't appear to solve
> the case where the called function fn lives in a different package, and
> takes an argument which is a private type. That is:
> >> >
> >> > -- a/a.go --
> >> > package a
> >> >
> >> > type myString string
> >> >
> >> > func Fn(str myString) { }
> >> >
> >> > -- b/b.go --
> >> > package b
> >> >
> >> > import "a"
> >> >
> >> > func rewrite() {
> >> > go a.Fn("some string")
> >> > }
> >> >
> >> > In this example knowing the desired type from the function signature
> does not help, I would think?
> >>
> >> That is correct.
> >>
> >> Fortunately for a case like that you don't need to use a temporary
> >> variable at all, since the argument is a constant.
> >>
> >> Ian
> >
> >
> > That makes sense. I did some more research and came across another case
> where even this might not work.
> > It appears that there is a distinction between an untyped value and an
> untyped constant. I hadn't appreciated this distinction until now.
> >
> > According to the spec (https://golang.org/ref/spec#Comparison_operators),
> "Comparison operators compare two operands and yield an untyped boolean
> value."
> > As a result, it's possible to get untyped, non-constant values from
> non-constant expressions.
> >
> > So we could have fn(a() == b()) passed to fn(b myBool) with no ability
> to store this argument in a temporary variable without coercing the type to
> a regular typed bool.
>
> Technically true but essentially never happens in practice.
>
> Ian
>
I suppose that's fair, but it's hard to come up with concrete rules for
what is permissible given a particular implementation of the rewrite, which
makes it hard to explain to potential users of the tool.
Switching gears a bit, I guess this might be easier to implement as a
modification to the compiler? Or can you think of another way of making the
general case more tractable?
Thanks,
André
--
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/2817e2e4-cc78-472e-bb06-7b0aa0322bdd%40googlegroups.com.
