We should support Implicit Member Expressions. Thi...

# language-proposals

[benleggiero]

We should support Implicit Member Expressions. This is something I enjoy at work with Swift, and drastically reduces boilerplate:

https://stackoverflow.com/questions/47023274/what-is-the-swift-syntax-bar-called

[umar]

I was thinking about something similar, but now I think it's not a good idea, because we should remember what is the receiver here. It is not what we want to do when we read the code.

[benleggiero]

It's very useful if you write good code. Compare:

// My idea in Kotlin:

context.drawImage(method = ImageDrawMethod.sourceAtop)
context.drawImage(method = .sourceAtop)


context.fillPath(color = Color.red) // Also note that this reads weird in English: "Context, fill path with color color red"
context.fillPath(color = .red) // Versus "Context, fill path with color red"


listOfDoubles.reduce(operation = Double::plus)
listOfDoubles.reduce(operation = .plus) // Ideally, this might even become `listOfDoubles.reduce(operation = +)`, but that's unrelated to this proposal :)


GrandparentClass.takeGrandchild(GrandparentClass.ParentClass.MyClass.predefined)
GrandparentClass.takeGrandchild(.predefined)


path.lineTo(Point.zero)
path.lineTo(.zero) // here's it's obvious what's required and what's going to happen. When constructing a path, move to and create lines to points. No other type makes sense to go here, so the type should be omitable

Note that in all of these examples, the intelligent omission of the class name does not make it more ambiguous. The type is easily implied, both by the compiler and by the human.

This is especially useful when you want to make a bunch of predefined instances of a class. Swift does this in many places, most notably with Notification.Name, to great effect, wrapping what used to be string literals inside a semantic class:

// Swift code:

// Swift 2 did it in one of these ways, where `post` took a `String`:
NSNotificationCenter.defaultCenter().post("SomeMagicalStringYouMustKnow")
NSNotificationCenter.defaultCenter().post(SomeGlobalConstantInASeaOfGlobalConstants)
NSNotificationCenter.defaultCenter().post(MyUtilities.MyNotificationNameConstant)



// Swift 3 did it like this, taking advantage of extensions, strong typing, and implicit member expressions. `post` takes a `Notification.Name`:
<http://NotificationCenter.default.post|NotificationCenter.default.post>(.constantFromFoundation)
<http://NotificationCenter.default.post|NotificationCenter.default.post>(.myNotificationNameConstant)
<http://NotificationCenter.default.post|NotificationCenter.default.post>(.init("SomeNotificationForWhichIDontWantAConstant"))

// The constants are declared like this:
public extension Notification.Name {
    public static let myNotificationNameConstant = Notification.Name("myNotification")
}

If Kotlin allowed this, then we could combine it with the IDE's autocomplete give a list of all valid values once the dot is typed. This eliminates a lot of useless/redundant code (like the name of a class that you already typed on the same line), makes it much more clear what goes where (turns magic numbers/strings/etc. and global variables into semantic values in predictable places), and reduces coding/reading effort (99.9% of the time I either intuitively know what type is going there, or I don't care; either way I don't need to see or write the type. In the remaining 00.1%, the type doesn't have to be omitted).

[gildor]

combine it with the IDE’s autocomplete give a list of all valid values once the dot is typed

Like IDE-only autocompletion feature it looks not bad actually.
btw we already have smart autocomplete that offers you only valid values, but maybe dot autocomplete would be helpful, especially with such context, because now if you start dot you don't get any helpful results

[gildor]

But I don’t think that it’s worth to add as language feature. “static” import + import aliases can cover most of use cases of this feature.
But again, I would support IDE feature

[gildor]

listOfDoubles.reduce(operation = .plus) // Ideally, this might even become

Don’t like this example with method reference, too ambiguous for me

[benleggiero]

@gildor Just one question, about your last comment: How is it ambiguous? If there were more than one plus operator that took 2 `Double`s and returned a Double, it wouldn't've compiled in the first place.