<commit_before>// errchk $G $D/$F.go

// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package main

type T struct {
	x, x int  // this should be a compile-time error
}

/*
Accessing obj.x for obj of type T will lead to an error so this cannot
be used in a program, but I would argue that this should be a compile-
tume error at the declaration point.
*/<commit_msg>- added comment with various viewpoints so we have whole story once we close this<commit_after>// errchk $G $D/$F.go

// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package main

type T struct {
	x, x int  // this should be a compile-time error
}

/*
Accessing obj.x for obj of type T will lead to an error so this cannot
be used in a program, but I would argue that this should be a compile-
tume error at the declaration point.
*/

/* Condensed e-mail thread:

---------- <NAME>	
I don't think this is an error as long as you don't refer to x. I like the fact that you could name
multiple elements in the struct "pad".


---------- <NAME> to Russ, me, go-dev, reviewlog2
the real question is whether this program matches the spec and if not, which is in error.


---------- <NAME> to Rob, me, go-dev, reviewlog2
true enough.  the spec disagrees with 6g.
when we discussed the disambiguation
rules for anonymous structs i thought we'd
mentioned this issue too and decided the
opposite, but i'm happy to make 6g agree
with the spec.


---------- <NAME> to Russ, Rob, go-dev, reviewlog2
I think the spec could perhaps be more definitive. Note that 6g also accepts:

type T struct {
	x int
}

func (p *T) x() {
}

func (p *T) x() {
}

The spec says that the scope of methods and fields is selectors of the form obj.selector. In a scope an identifier can be declared only once. I'd conclude that in the scope of fields and selectors of T, there are multiple x. But it's somewhat indirect. From a programmer's point of view making this an error seems less surprising, at least to me.


---------- <NAME> to me, Russ, Rob, go-dev, reviewlog2
obviously i dont think this is an error, or
i would have made it an error. it seems like
a small point if the error comes up at
declaration or use.


---------- <NAME> to Ken, Russ, Rob, go-dev, reviewlog2
I don't really care too much, but I think it should be consistent. The following code:

type T struct {
	x int;
}

func (p *T) x() {
}

func (p *T) x(a, b, c int) {
}

does result in an error (method redeclared). I don't quite see why this should behave any different then if both x() had the same parameter list.

PS: I agree that the spec is saying two different things here - or at least should be more precise; the section on selectors (which arguably is the newer section), would allow such a declaration. I suspect that the case below leads to an early error possibly due to some interaction with code that checks for forward declaration of functions/methods (this not having looked at 6g).

I am happy to go either way. It's a small item and we can close it once we all agree.
*/
{'fraction_non_alphanumeric': 0.08045977011494253, 'fraction_numerical': 0.005281143212177695, 'mean_word_length': 3.1818181818181817, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5406582', 'n_tokens_mistral': 929, 'n_tokens_neox': 896, 'n_words': 561}