_property as fallback shortcut to self.property

The motivation is pretty much the same as SE-0009

That is, we need a shorter form of self.property that is more readable at the point of use.

The idea is:

Add fallback lookup for identifier starts with single _ (ex. _name), if the identifier is not a local variable , member property or global variable, then treat it as self.(identifier without _) (ex. self.name)

Suppose the identifier lookup can be simplified as:

closure / function -> class / struct / enum member -> global variable

The fallback lookup is added after global variable lookup

closure / function -> class / struct / enum member -> global variable -> _ fallback lookup

This will avoid break existing source, and make this feature optional.

Additional restriction to the fallback lookup:

  1. it should apply to property only
  2. it should happen in the member function / constructor only
  3. it should apply to identifier starts with single _ char (double or more _ should not trigger this lookup)
  4. it should not apply to identifier that is explicitly bound (that is, with self. or instance.)
  5. compiler should issue warning if _identifier can be resolved as global variable and instance property at the same time
  6. optionally deprecate naming of property / global starts with single _
private var _name: String = "Steve"

class Person {
	var name: String = "David"
	var title: String = "Manager"
	var _phone: String?
	
	func foo() {
		print("Hello \(name)") // pickup self.name
		print("Hello \(_name)") // pickup global _name (not fallback) , and compiler issue warning
		print("Hello \(self.name)") // pickup self.name
		print("Hello \(self._name)") // compile error
		print("Hello \(_title)") // pickup self.title (fallback)
		print("Hello \(_phone)") // pickup self._phone (not fallback)
	}
}

I might be completely misunderstanding but I don't see why this is needed, you can just refer to the property name as is, without the self. As you have shown in the line print("Hello \(name)") // pickup self.name

1 Like

The point is to be more readable at the point of use (to know which is instance member or local variable).
It's like many other frameworks would require instance property to start with "m" or "m_", etc.

This is for style guidelines and/or a linter to enforce. Adding a shortcut for self. does not improve readability, nor does it enable any new functionality or expressiveness.

6 Likes

I probably won‘t support that idea personally because it feels counterintuitive to me

1 Like

How would this work with property wrappers? Since it will conflict with _propertyName backing variable which is synthesised by the compiler.

It wouldn‘t. As shown in the original example if the underscore identifier is already taken, the pitched functionality won‘t trigger at all. That‘s why I personally think it‘s counterintuitive as it highly relies on the context awareness of both the user and compiler.

7 Likes

-1

  • Unnecessary.
  • Too many ways to write the same thing is a detriment for learning/reading the language.
  • magic symbols to replace actual words just makes the language harder to learn for newcomers (ala pearl) and is not "more readable".
  • too little "gain" - 4 characters of typing - to be worth it.
6 Likes
Terms of Service

Privacy Policy

Cookie Policy