[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Matthew Johnson]

> On Jan 6, 2016, at 11:47 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I remember this being discussed in the conversation about this proposal and I haven't seen anyone being *against* there being a compiler flag, assuming it's off by default.
>> 
>> We don't want language-changing compiler flags. swiftc doesn't even have flags to control warnings today, though I don't know if we'll be able to preserve that forever.
>> 
>> Style rules should be enforced by tools other than the compiler. 
> 
> I tend to agree with Greg, in part because I don’t like the idea of having a cornucopia of potentially-conflicting warning flags for different coding conventions within the compiler proper (e.g., -Wimplicit-self vs. -Wunnecessarily-qualified-self, for the opposite ends of the spectrum in this particular debate).
> 
> The core team did talk about such a warning flag briefly, and there was no consensus either way. We think this needs more discussion in the community, but not as a discussion specific to requiring “self.”. Rather, the question is “does checking of coding conventions belong in the Swift compiler or in a separate tool?” and “how do we decide which coding conventions are important/popular/useful enough to include?”

I agree that this is an important discussion to have.  

A possible middle ground might be an external tool that is also available during compilation with a single  -Wstyle-violation warning.  The “style definition” for a module would need to be specified somewhere available to both.  This would definitely be preferable to a long list of style-specific warning flags IMO and would allow different teams to adopt different workflows.

Matthew

> 
> 	- Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution