Thus can create some subtle errors. Suppose T3’s field was named bar.
And the above example will print 1 for t1.foo. Now change T3 field to foo.
And t1.foo will be 2.
> On Oct 25, 2017, at 6:44 AM, Ian Lance Taylor wrote:
>
> I'll speculate that perhaps you would prefer a compilation error due
On Wed, Oct 25, 2017 at 1:43 AM, Harald Fuchs wrote:
>
> I got bitten by what I'd say is a misfeature in Go:
>
> type T1 struct {
> T2
> T3
> }
>
> type T2 struct {
> T4
> }
>
> type T3 struct {
> foo int
> }
>
> type T4 struct {
> foo int
> }
>
> func main()
On Wed, Oct 25, 2017 at 11:02 AM, Lutz Horn wrote:
> This prints "foo=2" which surprised me because I was unaware that T1
>> had got another foo via T3 (with less composition depth).
>>
>> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
>> (because the composition depth is t
This prints "foo=2" which surprised me because I was unaware that T1
had got another foo via T3 (with less composition depth).
If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
(because the composition depth is the same).
There is no ambiguity because `T4.foo` is not promote
I got bitten by what I'd say is a misfeature in Go:
type T1 struct {
T2
T3
}
type T2 struct {
T4
}
type T3 struct {
foo int
}
type T4 struct {
foo int
}
func main() {
t1 := T1{
T2{
T4{
1,
},
},
T3{
2,