[swift-evolution] My personal beef with leading-dot syntax

[Brent Royal-Gordon]

> When I have a context that demands an instance of a
> particular enum type, I think it's reasonable to look up the names in
> the enum without qualification, and I strongly question the value of
> leading-dot syntax for general static member lookup.  I would normally
> never think of using it that way—because, guess what? I think of
> leading-dot as a notation for enums like everybody else does—and I don't
> think there are any important idioms it supports, that couldn't be
> equally well handled by something like `Self.x` if we were allowed to
> use it.

Well, sure, they don't know that leading dot is more widely usable—"The Swift Programming Language" only mentions it in connection with enums. But once people know, they're very glad to use it.

I've introduced several different people to the joys of universal leading-dot syntax, and I would characterize their reaction as *pleasant* surprise. They immediately start using the syntax for things like `.blackColor()` and `.passRetained(_:)` and `.min`, and often expand their usage beyond that. Now that unbound methods are uncurried, a small tweak to the leading dot syntax in function context will also open us up to things like `views.forEach(.removeFromSuperview)`. Lens functions may also eventually be used in this way. 

If the feature is underused, that's because it's poorly explained, not because it's not widely desired.

(Besides, you probably at least use the syntax for option sets, which are enum-like but not enums.)

-- 
Brent Royal-Gordon
Architechies