[Review] SE-0066: Standardize function type argument syntax to require parentheses

James_F · April 27, 2016, 8:12pm

I'm surprised this could lead to confusion. I have never encountered any errors relating to the current behaviour. That the presence of brackets could mean a parameter list, or a function that takes a parameter, I could see as an extension of tuple splat, providing flexibility. However, since tuple splat has been removed for now, I understand why this might need rethinking.

Why this means we have to add brackets to functions taking a single type, where there is no ambiguity or possibility for confusion, I don't understand at all.

Tuple splat originally allowed generic types to use tuple parameters as generic parameter lists to functions, allowing great syntax for things like notification forwarding (see frameworks such as ObservableSwift), and I was sad to see that go. With Swift 3 I'll just have to live with double-bracketed parameter lists.

I was in favour of keeping tuple splat, but that was more of an edge case. I find myself using single-parameter function types regularly, and love what support for functional programming Swift provides. I am definitely in favour of allowing the bracketless syntax.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <8597386C-FE51-4156-9ECD-CEB11579C05C@apple.com>

Hello Swift community,

The review of SE-0066 "Standardize function type argument syntax to require parentheses" begins now and runs through May 2, 2016. The proposal is available here:

github.com

apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

# Standardize function type argument syntax to require parentheses

* Proposal: [SE-0066](0066-standardize-function-type-syntax.md)
* Author: [Chris Lattner](https://github.com/lattner)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html)
* Implementation: [apple/swift@3d2b5bc](https://github.com/apple/swift/commit/3d2b5bcc5350e1dea2ed8a0a95cd12ff5c760f24)

## Introduction

Function types in Swift use parentheses around their parameter list (aligning
with the function declaration syntax, as well as the syntax used to call a
function).  However, in the degenerate case of a single non-variadic, unlabeled
argument with no attributes, Swift allows the parentheses to be omitted.  For
example, these types:

```swift
(Int) -> Float
(String) -> Int

This file has been truncated. show original

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

github.com

apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

# Standardize function type argument syntax to require parentheses

* Proposal: [SE-0066](0066-standardize-function-type-syntax.md)
* Author: [Chris Lattner](https://github.com/lattner)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html)
* Implementation: [apple/swift@3d2b5bc](https://github.com/apple/swift/commit/3d2b5bcc5350e1dea2ed8a0a95cd12ff5c760f24)

## Introduction

Function types in Swift use parentheses around their parameter list (aligning
with the function declaration syntax, as well as the syntax used to call a
function).  However, in the degenerate case of a single non-variadic, unlabeled
argument with no attributes, Swift allows the parentheses to be omitted.  For
example, these types:

```swift
(Int) -> Float
(String) -> Int

This file has been truncated. show original

Reply text

Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

github.com

apple/swift-evolution/blob/master/process.md

# Swift Evolution Process

Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.

## Scope

The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on. Smaller changes, such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://swift.org/community/#contributing).

## Goals

The Swift evolution process aims to leverage the collective ideas, insights, and experience of the Swift community to improve the Swift development experience. Its two primary goals are:

* Engage the wider Swift community in the ongoing evolution of Swift, and
* Maintain the vision and conceptual coherence of Swift.

There is a natural tension between these two goals. Open evolution processes are, by nature, chaotic. Yet, maintaining a coherent vision for something as complicated as a programming language requires some level of coordination. The Swift evolution process aims to strike a balance that best serves the Swift community as a whole.

## Participation

Everyone is welcome to propose, discuss, and review ideas to improve

This file has been truncated. show original

Thank you,

Doug Gregor

Review Manager

------------- End Message -------------

From James F