After spending some time with the toolchain, I rather like it.
I’m a comfortable but not vehement +1 on this, with one caveat about function declarations.
- What is your evaluation of the proposal?
I came to it with mixed feelings.
On the one hand, I am an enthusiastic proponent of removing syntactic noise. I used to sneer at syntactic gymnastics to reduce delimeters, but actually working with languages that did such gymnastics convinced me of the readability benefit. It’s simply easier to see the code if there’s less visual distraction in it. I’ve come to believe that Edward Tufte’s “data-to-ink ratio” applies to code as much as any other form of information design.
On the other hand, this seemed like such a fiddly little change that it’s hardly worth the syntactic confusion I assumed it would create. And I assumed there would be lots — as there is with Javascript’s vexingly almost-but-not-quite-optional semicolons.
After spending some time with the toolchain, I didn’t find any Javascript-like bizarre corner cases, even with my bizarre taste in formatting. (Whitesmiths! don’t @ me) This proposal really does slip into the language with shocking ease, just as its authors suggest!
The result is often nothing more than a subtle and pleasant shift:
return RequestTransferMetrics(
requestBytesSent: task.countOfBytesSent
requestBytesTotal: task.countOfBytesExpectedToSend
responseBytesReceived: task.countOfBytesReceived
responseBytesTotal: task.countOfBytesExpectedToReceive)
…but in some cases opens up striking possibilities, as in this fussy little helper method that sans commas becomes reminiscent of Smalltalk’s conditionals:
withOwner(owner
ifObserver: {
observerIsOwner = false
}
else: {
externalOwners.insert(WeakRef(owner))
}
)
Here a print statement benefits from breaking a long string across lines:
print(
"WARNING: Received response for request that was already completed:"
delegate.requestDescription
"This may indicate a bug in your NetworkingProvider, your custom"
"RequestDelegate, or Siesta itself. If it is the latter, please"
"file a bug: https://github.com/bustoutsolutions/siesta/issues/new"
"\n Previously received:", existingResponse
"\n New response:", newResponse)
The real clincher for me is what the proposal does to SwiftPM package config:
let package = Package(
name: "Paper"
products: [
.executable(name: "tool", targets: ["tool"])
.library(name: "Paper", targets: ["Paper"])
]
dependencies: [
.package(url: "http://github.com/SwiftyJSON/SwiftyJSON", from: "1.2.3")
.package(url: "../CHTTPParser", .upToNextMinor(from: "2.2.0"))
.package(url: "http://some/other/lib", .exact("1.2.3"))
]
targets: [
.target(
name: "tool"
dependencies: [
"Paper"
"SwiftyJSON"
])
.target(
name: "Paper"
dependencies: [
"Basic"
.target(name: "Utility")
.product(name: "CHTTPParser")
])
]
)
That’s nice. The raggedy commas in Package.swift
always bother me!
The one snag I hit is that the proposal does not support comma elision in function signatures:
public func request(
_ method: RequestMethod // compiler error here
data: Data
contentType: String
requestMutation: @escaping RequestMutation = { _ in })
-> Request
The language really ought to support comma elision in the declaration, since it supports it in the corresponding call. It will certainly cause frustration otherwise.
- Is the problem being addressed significant enough to warrant a change to Swift?
This is certainly debatable (as the debate here shows).
Opening up the possibilities of more fluid and readable Swift DSLs seems to me to be worth the fuss, but I don’t have vehement feelings about this.
- Does this proposal fit well with the feel and direction of Swift?
To the extent that Swift goes out of its way to reduce visual noise (optional semicolons, type inference, .
-prefix use of the contextual type as an implicit namespace, trailing closures, anonymous closure args, type sugar for arrays and dicts), I’d say yes, it does fit with the feel of Swift.
To the extent that Swift is a C descendant, it feels odd. However, Swift is syntactically already a long way from C; see previous paragraph.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
My time with Ruby, Python, Smalltalk, and Elm — all relatively low-delimeter languages — has made me appreciate the value of reduced visual noise in code.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I only skimmed the proposal, but spent some quality time with the toolchain.