The spec uses "shallowest depth", not "shortest path", as I assume saying
"path" would imply the given names in a selector expression determine
ambiguity when they do not.
"shallowest depth" makes the error more clear in my sample where if this:
type Uniform GLUniform
is changed to this:
type Uniform struct {
GLUniform
}
access to the Value fields would now exist at the same depth and produce
the error I was expecting to see.
https://golang.org/ref/spec#Selectors
On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner <dan...@dasa.cc> wrote:
> Right, I've misunderstood why this error is thrown, as in what defines
> ambiguity. Text search of spec for "ambig" only yields results for
> composite literals and avoiding ambiguity in conversions while "shortest"
> yields no results and the only recollection of "shortest path wins" phrase
> I have is back when vendor directory was introduced.
>
> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>>
>> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner <dan...@dasa.cc> wrote:
>>
>> > https://play.golang.org/p/Y1UxMgNhWx
>> >
>> > I ran into this today but don't understand why the compiler isn't
>> throwing an ambiguous reference error. Maybe I've misunderstood why this
>> error is thrown the few times I've seen it.
>>
>> No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
>> and the other one is sample.Uniform.Value and the specs say the shortest
>> path wins.
>>
>> --
>>
>> -j
>>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
