[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions (David Hart)

James Dempsey dempsey at mac.com
Wed Dec 16 10:20:26 CST 2015


>> I think the mandatory self problem is analogous to never wanting to use x!, as! or try!. If you restrict yourself to always using self.whatever, it is not unusual to someone else, and if they leave off the compiler flag or pragma that enforces this, the code will still compile.

I think there is a fundamental difference between code that does / does not use x! as! or try! and code that may or may not require the use of self.

Even if you do not use x! as! or try! in your own code, you can easily read and understand code that does use those features.

But if you choose to enforce using self in your own code, suddenly you need to read and reason about code in two different ways.

In ‘mandatory self’ code, you can assume self is always being used and you cannot accidentally use something in local scope by mistake.  The ‘mandatory self’ removes a set of potential bugs you need to check for when reading code.  But when you encounter ’non enforced self’ code, you can’t make those assumptions and you need to check for those issues.

For me, choosing not to use x! as! or try!  in your code is like choosing not to use swear words when you speak. You easily understand them when someone else uses them, but you choose not to.

Being able to choose ‘mandatory self’ or not is more like a dialect. For each dialect you need to adjust your mental model of how the language works.

Overall, I am +1 for the proposal of making self mandatory because I find the lack of 'mandatory self' makes the code less readable, less explicit as to intent and can also introduce subtle bugs.

If it comes down to adding some sort of switch or not I am -1 for that because that does seem like the creation of two dialects of the language. 

James


> On Dec 15, 2015, at 9:54 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 15, 2015, at 8:10 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> This is the full text of what Chris said in regard to “Proposal: Add Flags to Disable [Optional] Conversions"
>> 
>>> I don’t like the idea of having different incompatible dialects, and behavior changing modes.  That said, I’m personally not opposed to providing functionality that would enable people to use a reduced subsets of the language, and have the compiler enforce it.  For example, I don’t have a problem with someone saying they never want to use the x!, as!, try! family and have the compiler tell them if they do.
>>> 
>>> To relate this to your question, I’d be fine with functionality that causes the compiler to produce an error when code requires an implicit conversion, but I wouldn’t want them to be just “disabled”, because I think this could change the interpretation of valid swift code (in admittedly weird cases).
>>> 
>>> In terms of how to express this, I’m not in love with modal compiler flags :-).  I’d much rather this sort of requirement be specified as a pragma-like construct that applies to an arbitrary scope (e.g. class or function body) or a whole file.  This keeps the code self describing.
>> 
>> I think the mandatory self problem is analogous to never wanting to use x!, as! or try!. If you restrict yourself to always using self.whatever, it is not unusual to someone else, and if they leave off the compiler flag or pragma that enforces this, the code will still compile.
> 
> I agree with you.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list