Dot notation as shorthand in subscripts and functions

So there’s a discussion at the moment about dot notation in switch statements, and it reminds me that I actually would like to see the dot notation expanded beyond switches.

When used in a switch statement the dot notation is a kind of shorthand reference to the type of an enum, but it also seems like for non enums it could be a shorthand reference to self, allowing us to avoid having to write out variable references in a few common cases.

For example, consider the following:

myObject.myArray[myObject.myArray.startIndex] = 0
myObject.myFunction(myObject.someValue)

What I’d love to be able to do is simplify these to the following:

myObject.myArray[.startIndex] = 0
myObject.myFunction(.someValue)

In essence the dot in these cases represents a reference to the object or struct to which the subscript or function belongs, eliminating the need to enter that yet again (or extract into a variable just for neatness).

The only issue I see is if a parameter is an enum, as it could be ambiguous which shorthand is being used, though this is only really an issue if the type has a property with an identical name to an enum case:

enum MyEnum { .One, .Two }
class MyClass {
  var One = “this is a bad idea"
  func myFunction(mode:MyEnum) { /* Do something */ }
}

var myObject = MyClass()
myObject.myFunction(.One) // Ambiguous, could be myObject.One or MyEnum.One

However, this is a pretty unlikely case since both the type needs to have a property with exactly the same name as one of the enum’s cases, so most of the time the compiler should be able to decide which was meant. It’s even less likely when considering that convention seems to be for enum cases to start with a capital letter, while properties begin with lowercase letters, though there may be an argument that the test for ambiguity should be case insensitive (to protect against typos). However, it’s also possible that when a property and enum case name conflicts that only one will be a valid argument for the subscript/function anyway, so that’s another way that ambiguity can be avoided too.

When used in a switch statement the dot notation is a kind of shorthand reference to the type of an enum, but it also seems like for non enums it could be a shorthand reference to self, allowing us to avoid having to write out variable references in a few common cases.

I think you don't realize how broad the existing leading-dot feature is.

Leading dot can be used in any place where a type can be inferred to access a static member of that type. For instance, it also allows this:

  textField.textColor = .whiteColor()

Because it's not limited to just enums, the existing meaning would almost *always* conflict with the meaning you propose.

···

--
Brent Royal-Gordon
Architechies

When used in a switch statement the dot notation is a kind of shorthand reference to the type of an enum, but it also seems like for non enums it could be a shorthand reference to self, allowing us to avoid having to write out variable references in a few common cases.

I think you don't realize how broad the existing leading-dot feature is.

Leading dot can be used in any place where a type can be inferred to access a static member of that type. For instance, it also allows this:

  textField.textColor = .whiteColor()

Because it's not limited to just enums, the existing meaning would almost *always* conflict with the meaning you propose.

Not exactly what is discussed in this thread, but there is a way to expand the dot shorthand without overlapping the current shorthand: [swift-evolution] [Proposal Idea] dot shorthand for instance members

···

On Jan 16, 2016, at 4:24 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hmm, that’s a shame, as other than switch cases I don’t use the leading-dot notation for anything else; personally I’d find it much more useful as a shorthand for cutting boilerplate around instances, as they can more easily become nested deeply than statics.

That said, I disagree that this behaviour would mean that it will “always” conflict; as with an enum argument it will still only conflict if the type has both a local and static item with exactly the same name.

In your example, textColor’s type would need to have both a static and local .whiteColor() that could result in ambiguity, which seems unlikely. If there’s only a static whiteColor then there’s no ambiguity.

···

On 16 Jan 2016, at 10:24, Brent Royal-Gordon <brent@architechies.com> wrote:

When used in a switch statement the dot notation is a kind of shorthand reference to the type of an enum, but it also seems like for non enums it could be a shorthand reference to self, allowing us to avoid having to write out variable references in a few common cases.

I think you don't realize how broad the existing leading-dot feature is.

Leading dot can be used in any place where a type can be inferred to access a static member of that type. For instance, it also allows this:

  textField.textColor = .whiteColor()

Because it's not limited to just enums, the existing meaning would almost *always* conflict with the meaning you propose.

--
Brent Royal-Gordon
Architechies