On Fri, Nov 8, 2019 at 1:38 PM André Eriksson <ean...@gmail.com> wrote:
>
> 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> 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.
The case where you have trouble is code that uses an unexported type
set as bool, functions that take parameters of that type that are
invoked by the go statement, and arguments passed as comparisons. I
would be mildly surprised if any such code exists anywhere. And even
then you could still make it work by using temporaries for the
operands of the comparison, and keeping the comparison unchanged in
the actual call to the function.
> 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?
This could be done by modifying the compiler but it's unlikely that
the compiler change would be accepted in the master sources.
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/CAOyqgcWATo%3Dt7GpVB8AiN_X2XXP9XkUWUV7c_51FzJ3LUC9N-Q%40mail.gmail.com.
