> On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
> I am not a fan of this syntax. `;` reads very strongly as a statement ender
> to me,
Technically speaking, Swift uses semicolon as a separator, not a line ender.
We already use it to separate multiple expressions on the same line, typically
when those expressions are side effecting:
print(“foo”); print(“bar”) // silly example
The proposal is consistent with this usage.
> and yet at the same time, it's still visually quite close to `,`. My first
> impression was that the proposal had an embarrassing typo in the very first
> example.
Particularly if we end up with Matthew’s proposal to allow omitting the
semicolon when it is at the end of the line, I think we’d end up with much
nicer looking code in practice. Here are a couple of random example conditions
I pulled from AlamoFire (feel free to pick some of your own):
Now:
if let
path = fileURL.path,
fileSize = try
NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as?
NSNumber
{
guard let
path = fileURL.path
where NSFileManager.defaultManager().fileExistsAtPath(path,
isDirectory: &isDirectory) && !isDirectory else
{
if let path = fileURL.path where
NSFileManager.defaultManager().fileExistsAtPath(path) {
With SE-0099 + Matthew’s extension, this could be written more nicely as:
if let path = fileURL.path
let fileSize = try
NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as?
NSNumber
{
guard let path = fileURL.path
NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory:
&isDirectory)
!isDirectory else
{
if let path = fileURL.path;
NSFileManager.defaultManager().fileExistsAtPath(path) {
To be clear, I’m not saying I prefer alamofire’s indentation style :-)
> My suggestion would be to reuse our normal && operator:
>
> guard
> x == 0 &&
> let y = optional &&
> z == 2
> else { ... }
>
> This would obviously be a built-in `&&` separate from our existing, infix
> operator `&&`.
Yes, this is technically feasible, but it has the opposite problem from the
above: && is very closely associated (in terms of programmer mindspace) with
boolean conditionals, and the let/case clauses are *not* boolean conditions.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
