[Proposal] [Stage–2] `return` consistency for single-expressions


(Adrian Zubarev) #1

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

return consistency for single-expressions

Proposal: SE-NNNN
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

Any single-expression closure can omit the return statement. This proposal aims to make this feature more consistent in some other corners of the language.

Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for single-expressions * [Pitch] (Bofore Swift 3) Make return optional in computed properties for a single case

Motivation

Closures can omit the return and have an inferred return type:

let _ = { 42 } // Type: () -> Int

let _ = [1,2,3].map { $0 * 5 } // T == Int
There are also value returning code blocks in the language that feel the same but are inconsistent to the mentioned feature:

// Read-write computed property:
var integer: Int {
    get { return 2016 }
    set { /* do some work */ }
}

// Read-only computed property:
var string: String { return "hello swift" }

// Function:
func pi() -> Double {
    return 3.141
}

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { return index % 2 }
    set { /* do some work */ }
}

// Read-only subscript:
subscript(index: Int) -> Int { return index * 2 }
Proposed solution

Make return optional for the following top level code blocks that only contain a single expression:

variable-declaration
getter-setter-block
getter-clause
function-body
subscript-declaration
That will allow us to rewrite the above example to:

// Read-Write computed property:
var integer: Int {
    get { 2016 }
    ...
}

// Read-only computed property:
var string: String { "hello swift" }

// Function:
func pi() -> Double { 3.141 }

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { index % 2 }
    ...
}

// Read-only subscript:
subscript(index: Int) -> Int { index * 2 }
Possible real world example:

// Today
public struct Character {
     
    public let source: Module.Source
    private let _pointer: UnsafePointer<Swift.Character>
     
    public var value: Swift.Character {
        return self._pointer.pointee
    }
    ...
}

// Rewritten:
public struct Character {
    ...
    public var value: Swift.Character { self._pointer.pointee }
    ...
}
Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.

···

--
Adrian Zubarev
Sent with Airmail


(Matthew Johnson) #2

+1. I have always thought this sugar should be consistent throughout the language.

···

On Feb 17, 2017, at 2:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608
return consistency for single-expressions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
Author: Adrian Zubarev <https://github.com/DevAndArtist>
Status: Awaiting review <x-msg://423/#rationale>
Review manager: TBD
Introduction

Any single-expression closure can omit the return statement. This proposal aims to make this feature more consistent in some other corners of the language.

Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for single-expressions <applewebdata://86ADDB79-FDC5-4935-A422-C0817D7EEFA1> * [Pitch] (Bofore Swift 3) Make return optional in computed properties for a single case <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>
Motivation

Closures can omit the return and have an inferred return type:

let _ = { 42 } // Type: () -> Int

let _ = [1,2,3].map { $0 * 5 } // T == Int
There are also value returning code blocks in the language that feel the same but are inconsistent to the mentioned feature:

// Read-write computed property:
var integer: Int {
    get { return 2016 }
    set { /* do some work */ }
}

// Read-only computed property:
var string: String { return "hello swift" }

// Function:
func pi() -> Double {
    return 3.141
}

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { return index % 2 }
    set { /* do some work */ }
}

// Read-only subscript:
subscript(index: Int) -> Int { return index * 2 }
Proposed solution

Make return optional for the following top level code blocks that only contain a single expression:

variable-declaration
getter-setter-block
getter-clause
function-body
subscript-declaration
That will allow us to rewrite the above example to:

// Read-Write computed property:
var integer: Int {
    get { 2016 }
    ...
}

// Read-only computed property:
var string: String { "hello swift" }

// Function:
func pi() -> Double { 3.141 }

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { index % 2 }
    ...
}

// Read-only subscript:
subscript(index: Int) -> Int { index * 2 }
Possible real world example:

// Today
public struct Character {
     
    public let source: Module.Source
    private let _pointer: UnsafePointer<Swift.Character>
     
    public var value: Swift.Character {
        return self._pointer.pointee
    }
    ...
}

// Rewritten:
public struct Character {
    ...
    public var value: Swift.Character { self._pointer.pointee }
    ...
}
Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #3

Such something went wrong with the `[Stage-2]` annotation?

···

--
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 09:20:41, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

return consistency for single-expressions

Proposal: SE-NNNN
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

Any single-expression closure can omit the return statement. This proposal aims to make this feature more consistent in some other corners of the language.

Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for single-expressions * [Pitch] (Bofore Swift 3) Make return optional in computed properties for a single case

Motivation

Closures can omit the return and have an inferred return type:

let _ = { 42 } // Type: () -> Int

let _ = [1,2,3].map { $0 * 5 } // T == Int
There are also value returning code blocks in the language that feel the same but are inconsistent to the mentioned feature:

// Read-write computed property:
var integer: Int {
    get { return 2016 }
    set { /* do some work */ }
}

// Read-only computed property:
var string: String { return "hello swift" }

// Function:
func pi() -> Double {
    return 3.141
}

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { return index % 2 }
    set { /* do some work */ }
}

// Read-only subscript:
subscript(index: Int) -> Int { return index * 2 }
Proposed solution

Make return optional for the following top level code blocks that only contain a single expression:

variable-declaration
getter-setter-block
getter-clause
function-body
subscript-declaration
That will allow us to rewrite the above example to:

// Read-Write computed property:
var integer: Int {
    get { 2016 }
    ...
}

// Read-only computed property:
var string: String { "hello swift" }

// Function:
func pi() -> Double { 3.141 }

// Read-Write subscript:
subscript(index: Int) -> Int {
    get { index % 2 }
    ...
}

// Read-only subscript:
subscript(index: Int) -> Int { index * 2 }
Possible real world example:

// Today
public struct Character {
      
    public let source: Module.Source
    private let _pointer: UnsafePointer<Swift.Character>
      
    public var value: Swift.Character {
        return self._pointer.pointee
    }
    ...
}

// Rewritten:
public struct Character {
    ...
    public var value: Swift.Character { self._pointer.pointee }
    ...
}
Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.

--
Adrian Zubarev
Sent with Airmail


(Vladimir) #4

I think I like this, but what about guard?

func f(x: Int) -> Int {
  guard x > 0 else { return 0 }
...
}

vs

func f(x: Int) -> Int {
  guard x > 0 else { 0 }
...
}

?

···

On 17.02.2017 11:20, Adrian Zubarev via swift-evolution wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3.
This proposal has a small improvement to the language compared to other big
features currently being proposed. It almost feels like a bug fix rather
than a new feature, but it still needs a full and quick review process.

You can read the formatted version here:
https://github.com/apple/swift-evolution/pull/608

  >return> consistency for single-expressions

  * Proposal: SE-NNNN
    <https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
  * Author: Adrian Zubarev <https://github.com/DevAndArtist>
  * Status: *Awaiting review*
  * Review manager: TBD

    Introduction

Any single-expression closure can omit the |return| statement. This
proposal aims to make this feature more consistent in some other corners of
the language.

Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
computed properties for a single case
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>

    Motivation

Closures can omit the |return| and have an inferred return type:

>let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |

There are also value returning code blocks in the language that feel the
same but are inconsistent to the mentioned feature:

>// Read-write computed property: var integer: Int { get { return 2016 } set
{ /* do some work */ } } // Read-only computed property: var string: String
{ return "hello swift" } // Function: func pi() -> Double { return 3.141 }
// Read-Write subscript: subscript(index: Int) -> Int { get { return index
% 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
Int) -> Int { return index * 2 } |

    Proposed solution

Make |return| optional for the following top level code blocks that only
contain a single expression:

  * /variable-declaration/
  * /getter-setter-block/
  * /getter-clause/
  * /function-body/
  * /subscript-declaration/

That will allow us to rewrite the above example to:

>// Read-Write computed property: var integer: Int { get { 2016 } ... } //
Read-only computed property: var string: String { "hello swift" } //
Function: func pi() -> Double { 3.141 } // Read-Write subscript:
subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
subscript: subscript(index: Int) -> Int { index * 2 } |

*Possible real world example:*

>// Today public struct Character { public let source: Module.Source private
let _pointer: UnsafePointer<Swift.Character> public var value:
Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
struct Character { ... public var value: Swift.Character {
self._pointer.pointee } ... } |

    Impact on existing code

None, this change will only relax some existing rules.

    Alternatives considered

Leave this as is and live with such inconsistency.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #5

Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.

I’m also pretty opposed to doing it at any time. The rationale of “implicit return” in closures is specifically because they are limited to a single expression, which makes the semantics “obvious”. This was carefully considered.

-Chris

···

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608


(Matthew Johnson) #6

I think I like this, but what about guard?

func f(x: Int) -> Int {
  guard x > 0 else { return 0 }
...
}

vs

func f(x: Int) -> Int {
  guard x > 0 else { 0 }

}

Any time you have a guard statement you no longer have a single expression. There is at least one expression in the guard clause itself, at least one in the else block, and at least one following the guard statement.

···

On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

?

On 17.02.2017 11:20, Adrian Zubarev via swift-evolution wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3.
This proposal has a small improvement to the language compared to other big
features currently being proposed. It almost feels like a bug fix rather
than a new feature, but it still needs a full and quick review process.

You can read the formatted version here:
https://github.com/apple/swift-evolution/pull/608

>return> consistency for single-expressions

* Proposal: SE-NNNN
   <https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
* Author: Adrian Zubarev <https://github.com/DevAndArtist>
* Status: *Awaiting review*
* Review manager: TBD

   Introduction

Any single-expression closure can omit the |return| statement. This
proposal aims to make this feature more consistent in some other corners of
the language.

Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
computed properties for a single case
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>

   Motivation

Closures can omit the |return| and have an inferred return type:

>let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |

There are also value returning code blocks in the language that feel the
same but are inconsistent to the mentioned feature:

>// Read-write computed property: var integer: Int { get { return 2016 } set
{ /* do some work */ } } // Read-only computed property: var string: String
{ return "hello swift" } // Function: func pi() -> Double { return 3.141 }
// Read-Write subscript: subscript(index: Int) -> Int { get { return index
% 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
Int) -> Int { return index * 2 } |

   Proposed solution

Make |return| optional for the following top level code blocks that only
contain a single expression:

* /variable-declaration/
* /getter-setter-block/
* /getter-clause/
* /function-body/
* /subscript-declaration/

That will allow us to rewrite the above example to:

>// Read-Write computed property: var integer: Int { get { 2016 } ... } //
Read-only computed property: var string: String { "hello swift" } //
Function: func pi() -> Double { 3.141 } // Read-Write subscript:
subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
subscript: subscript(index: Int) -> Int { index * 2 } |

*Possible real world example:*

>// Today public struct Character { public let source: Module.Source private
let _pointer: UnsafePointer<Swift.Character> public var value:
Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
struct Character { ... public var value: Swift.Character {
self._pointer.pointee } ... } |

   Impact on existing code

None, this change will only relax some existing rules.

   Alternatives considered

Leave this as is and live with such inconsistency.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #7

Exactly, couldn’t say that any better. guard was part of this proposal in the first draft but was dropped due the same reasons Matthew just described.

···

--
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 15:46:33, Matthew Johnson (matthew@anandabits.com) schrieb:

On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

I think I like this, but what about guard?

func f(x: Int) -> Int {
guard x > 0 else { return 0 }
...
}

vs

func f(x: Int) -> Int {
guard x > 0 else { 0 }

}

Any time you have a guard statement you no longer have a single expression. There is at least one expression in the guard clause itself, at least one in the else block, and at least one following the guard statement.

?

On 17.02.2017 11:20, Adrian Zubarev via swift-evolution wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3.
This proposal has a small improvement to the language compared to other big
features currently being proposed. It almost feels like a bug fix rather
than a new feature, but it still needs a full and quick review process.

You can read the formatted version here:
https://github.com/apple/swift-evolution/pull/608

>return> consistency for single-expressions

* Proposal: SE-NNNN
<https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
* Author: Adrian Zubarev <https://github.com/DevAndArtist>
* Status: *Awaiting review*
* Review manager: TBD

Introduction

Any single-expression closure can omit the |return| statement. This
proposal aims to make this feature more consistent in some other corners of
the language.

Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
computed properties for a single case
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>

Motivation

Closures can omit the |return| and have an inferred return type:

>let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |

There are also value returning code blocks in the language that feel the
same but are inconsistent to the mentioned feature:

>// Read-write computed property: var integer: Int { get { return 2016 } set
{ /* do some work */ } } // Read-only computed property: var string: String
{ return "hello swift" } // Function: func pi() -> Double { return 3.141 }
// Read-Write subscript: subscript(index: Int) -> Int { get { return index
% 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
Int) -> Int { return index * 2 } |

Proposed solution

Make |return| optional for the following top level code blocks that only
contain a single expression:

* /variable-declaration/
* /getter-setter-block/
* /getter-clause/
* /function-body/
* /subscript-declaration/

That will allow us to rewrite the above example to:

>// Read-Write computed property: var integer: Int { get { 2016 } ... } //
Read-only computed property: var string: String { "hello swift" } //
Function: func pi() -> Double { 3.141 } // Read-Write subscript:
subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
subscript: subscript(index: Int) -> Int { index * 2 } |

*Possible real world example:*

>// Today public struct Character { public let source: Module.Source private
let _pointer: UnsafePointer<Swift.Character> public var value:
Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
struct Character { ... public var value: Swift.Character {
self._pointer.pointee } ... } |

Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #8

OK, just wanted to confirm that you are not suggesting to allow this in 'guard'.

···

On 17.02.2017 18:57, Adrian Zubarev via swift-evolution wrote:

Exactly, couldn’t say that any better. |guard| was part of this proposal in
the first draft but was dropped due the same reasons Matthew just described.

--
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 15:46:33, Matthew Johnson (matthew@anandabits.com
<mailto:matthew@anandabits.com>) schrieb:

> On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
>
> I think I like this, but what about guard?
>
> func f(x: Int) -> Int {
> guard x > 0 else { return 0 }
> ...
> }
>
> vs
>
> func f(x: Int) -> Int {
> guard x > 0 else { 0 }
> …
> }

Any time you have a guard statement you no longer have a single
expression. There is at least one expression in the guard clause itself,
at least one in the else block, and at least one following the guard
statement.

>
> ?
>
> On 17.02.2017 11:20, Adrian Zubarev via swift-evolution wrote:
>> I’d like to revive an additive proposal that couldn’t make it into Swift 3.
>> This proposal has a small improvement to the language compared to other big
>> features currently being proposed. It almost feels like a bug fix rather
>> than a new feature, but it still needs a full and quick review process.
>>
>> You can read the formatted version here:
>> https://github.com/apple/swift-evolution/pull/608
>>
>> >return> consistency for single-expressions
>>
>> * Proposal: SE-NNNN
>> <https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
>> * Author: Adrian Zubarev <https://github.com/DevAndArtist>
>> * Status: *Awaiting review*
>> * Review manager: TBD
>>
>> Introduction
>>
>> Any single-expression closure can omit the |return| statement. This
>> proposal aims to make this feature more consistent in some other corners of
>> the language.
>>
>> Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
>> for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
>> computed properties for a single case
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>
>>
>> Motivation
>>
>> Closures can omit the |return| and have an inferred return type:
>>
>> >let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |
>>
>> There are also value returning code blocks in the language that feel the
>> same but are inconsistent to the mentioned feature:
>>
>> >// Read-write computed property: var integer: Int { get { return 2016 } set
>> { /* do some work */ } } // Read-only computed property: var string: String
>> { return "hello swift" } // Function: func pi() -> Double { return 3.141 }
>> // Read-Write subscript: subscript(index: Int) -> Int { get { return index
>> % 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
>> Int) -> Int { return index * 2 } |
>>
>> Proposed solution
>>
>> Make |return| optional for the following top level code blocks that only
>> contain a single expression:
>>
>> * /variable-declaration/
>> * /getter-setter-block/
>> * /getter-clause/
>> * /function-body/
>> * /subscript-declaration/
>>
>> That will allow us to rewrite the above example to:
>>
>> >// Read-Write computed property: var integer: Int { get { 2016 } ... } //
>> Read-only computed property: var string: String { "hello swift" } //
>> Function: func pi() -> Double { 3.141 } // Read-Write subscript:
>> subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
>> subscript: subscript(index: Int) -> Int { index * 2 } |
>>
>> *Possible real world example:*
>>
>> >// Today public struct Character { public let source: Module.Source private
>> let _pointer: UnsafePointer<Swift.Character> public var value:
>> Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
>> struct Character { ... public var value: Swift.Character {
>> self._pointer.pointee } ... } |
>>
>> Impact on existing code
>>
>> None, this change will only relax some existing rules.
>>
>> Alternatives considered
>>
>> Leave this as is and live with such inconsistency.
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Nattinger) #9

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.

Not that I’m necessarily in favor of this change, but my impression was that the whole point of stage 1/2 was that anything not allowed in stage 1 is fair game in stage 2 (if it happens; that doesn’t seem to be likely at this point). What exactly is the goal of stage 2 then, should there actually be time for it?

···

On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’m also pretty opposed to doing it at any time. The rationale of “implicit return” in closures is specifically because they are limited to a single expression, which makes the semantics “obvious”. This was carefully considered.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #10

I was a little afraid of that when I read Teds message first, but I thought I give it a try. This additional change doest feel heavy at all to me.

My question is, when is the right time for this if not now? If not now than this won’t happen in Swift 4.1 either, and I highly doubt it for Swift 5, because then we’re probably going to focus on ABI again to get it finally done.

If that change could be accepted, than just leave it until someone had some time to implement it. That means if no one had time for Swift 4, then it might happen in Swift 4.1. The point is that it will potentially happen at some point, because it would be already accepted.

Furthermore I think such _smaller_ proposals are more attractive to people who wants to jump in and contribute to Swift, but might not want to start with heavy features like ‘Conditional conformances’.

I really would like the core team to consider this proposal for a review. :slight_smile:

···

--
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 04:33:13, Chris Lattner (clattner@nondot.org) schrieb:

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.

I’m also pretty opposed to doing it at any time. The rationale of “implicit return” in closures is specifically because they are limited to a single expression, which makes the semantics “obvious”. This was carefully considered.

-Chris


(Xiaodi Wu) #11

Ted Kremenek just wrote a post detailing Swift 4 stage 2. Here is the
relevant part again [unable to increase the quotation level for unclear
reasons, but the following is a verbatim copy from that message]:
Timeline

Stage 2 starts right now. All design work and discussion for stage 2
extends to *April 1, 2017*. The intent is to timebox discussion to provide
adequate time for the actual implementation of accepted proposals.
Scope

Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2
proposals may include some additive changes and changes to existing
features that don't affect the ABI. There are a few focus areas for Swift 4
stage 2:

···

-

   *Stage 1 proposals*: Any proposal that would have been eligible for
   stage 1 is a priority for stage 2.
   -

   *Source-breaking changes*: The Swift 4 compiler will provide a
   source-compatibility mode to allow existing Swift 3 sources to compile, but
   source-breaking changes can manifest in "Swift 4" mode. That said, changes
   to fundamental parts of Swift's syntax or standard library APIs that breaks
   source code are better front-loaded into Swift 4 than delayed until later
   releases. Relative to Swift 3, the bar for such changes is significantly
   higher:
   - The existing syntax/API being changed must be *actively harmful*.
      - The new syntax/API must *clearly* be better and not conflict with
      existing Swift syntax.
      - There must be a *reasonably automatable migration path* for
      existing code.
   -

   *Improvements to existing Standard Library facilities*: Additive changes
   that improve existing standard library facilities can be considered. With
   standard library additions in particular, proposals that provide
   corresponding implementations are preferred. Potential focus areas for
   improvement include collections (e.g., new collection algorithms) and
   improvements to the ergonomics of Dictionary.
   -

   *Foundation improvements*: We anticipate proposing some targeted
   improvements to Foundation API to continue the goal of making the Cocoa SDK
   work seamlessly in Swift. Details on the specific goals will be provided as
   we get started on Swift 4 stage 2.

On Sat, Feb 18, 2017 at 11:59 PM, Kevin Nattinger via swift-evolution < swift-evolution@swift.org> wrote:

On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift
3. This proposal has a small improvement to the language compared to other
big features currently being proposed. It almost feels like a bug fix
rather than a new feature, but it still needs a full and quick review
process.

You can read the formatted version here: https://github.com/
apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature
that fits the goal of Swift 4 stage 2.

Not that I’m necessarily in favor of this change, but my impression was
that the whole point of stage 1/2 was that anything not allowed in stage 1
is fair game in stage 2 (if it happens; that doesn’t seem to be likely at
this point). What exactly is the goal of stage 2 then, should there
actually be time for it?

I’m also pretty opposed to doing it at any time. The rationale of
“implicit return” in closures is specifically because they are limited to a
single expression, which makes the semantics “obvious”. This was carefully
considered.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #12

As Xiaodi mentioned downthread, that is not the case. Swift 4 stage 2 has specific changes that are accepted, because it has a fixed schedule and we have to prioritize the most important things for the community.

The art of evolving Swift forward is to carefully pick and choose areas to focus on, both because we want to ensure a coherent language, but also because implementor bandwidth is limited.

Beyond that, though syntactic sugar is always motivated by strong rationale and use-cases, in my opinion, it is the most dangerous kind of additive feature to consider at this point of Swift’s evolution. While these features are useful, they also clearly add complexity to the language, and it is difficult to gauge whether the problem being addressed will even exist in Swift as the other bigger features come in (for example, a macro system). These features can also make future language evolution more problematic because they consume syntactic real estate in the language.

If you’re into analogies, I see features like the generics improvements, ownership model, concurrency model, macro system, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, syntactic sugar proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.

-Chris

···

On Feb 18, 2017, at 9:59 PM, Kevin Nattinger <swift@nattinger.net> wrote:

On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.

Not that I’m necessarily in favor of this change, but my impression was that the whole point of stage 1/2 was that anything not allowed in stage 1 is fair game in stage 2 (if it happens; that doesn’t seem to be likely at this point). What exactly is the goal of stage 2 then, should there actually be time for it?


Shorthand syntax when variable name matches argument label?
(Rien) #13

Amen!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

···

On 19 Feb 2017, at 19:14, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 18, 2017, at 9:59 PM, Kevin Nattinger <swift@nattinger.net> wrote:

On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.

You can read the formatted version here: https://github.com/apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.

Not that I’m necessarily in favor of this change, but my impression was that the whole point of stage 1/2 was that anything not allowed in stage 1 is fair game in stage 2 (if it happens; that doesn’t seem to be likely at this point). What exactly is the goal of stage 2 then, should there actually be time for it?

As Xiaodi mentioned downthread, that is not the case. Swift 4 stage 2 has specific changes that are accepted, because it has a fixed schedule and we have to prioritize the most important things for the community.

The art of evolving Swift forward is to carefully pick and choose areas to focus on, both because we want to ensure a coherent language, but also because implementor bandwidth is limited.

Beyond that, though syntactic sugar is always motivated by strong rationale and use-cases, in my opinion, it is the most dangerous kind of additive feature to consider at this point of Swift’s evolution. While these features are useful, they also clearly add complexity to the language, and it is difficult to gauge whether the problem being addressed will even exist in Swift as the other bigger features come in (for example, a macro system). These features can also make future language evolution more problematic because they consume syntactic real estate in the language.

If you’re into analogies, I see features like the generics improvements, ownership model, concurrency model, macro system, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, syntactic sugar proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.

-Chris