I consider foo.bar and f.b to be of the same length, as in length of a
list, 2 in this case, not length of a string. But I failed to be clear
about it.
On Sun, Nov 5, 2017, 17:38 Daniel Skinner <dan...@dasa.cc> wrote:
> > I don't know when the shallowest depth can occur while not being on
> shortest path
>
> I know the feeling if we're generally talking about data structures and
> algorithms, but with regards to language spec, the only mental reference I
> have for "path" is for "import paths" of which the actual name is
> important. Searching the spec for "path" in fact only turns up references
> to import path.
>
> So on sight, I assumed "shortest path" meant changing `Texture` to `Tex`
> would affect resolution, which I also knew to be incorrect. It's my own
> failing but thanks for pointing me in the right direction as I was at a
> loss for where to even start as the visual cue of `type A B` vs `type A
> struct {B}` didn't register wrt the desired error for me.
>
> On Sun, Nov 5, 2017 at 10:09 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> I don't know when the shallowest depth can occur while not being on
>> shortest path. Note that path was used in this discussion as meaning full,
>> unpromoted path, ie. like if every embedded field of type T was declared T
>> T instead. The actual selector expression is a prefix of this full path.
>>
>> On Sun, Nov 5, 2017, 16:59 Daniel Skinner <dan...@dasa.cc> wrote:
>>
>>> 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
>>>>>
>>>> --
>>
>> -j
>>
> --
-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.
