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.