Proposal: optionally define nested functions elsewhere

Evolution Discussion
1

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
  var x:Int
  func g(y:String) {
    print(“x=\(x), y=\(y)")
  }
  ...
}

could be refactored as:

func f() {
  var x:Int
  func g(y:String) // function body elsewhere to avoid clutter in f
  ...
}

func f().g(y:String) {
    print(“x=\(x), y=\(y)")
}

2

I see two issues with this.

People might mistakenly think from the definition that they could call directly:
f().g("blah")
which they cannot, as g() can only be called within f(); g() is a private function of f() and used variables defined within f().

When changing the code, like renaming variable x, it make it a little harder to find all instance of x to properly asses the impact of the change. A function variable change need to be analyzed as a file scoped change.

Dany

···

Le 7 févr. 2016 à 09:32, Amir Michail via swift-evolution <swift-evolution@swift.org> a écrit :

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
   print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
   print(“x=\(x), y=\(y)")
}

3

I don’t think this fits well in the current design of Swift. It reminds me a lot of (Obj-)C-style headers, which Swift abandoned.

- Alex

···

On 07 Feb 2016, at 15:32, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
   print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
   print(“x=\(x), y=\(y)")
}

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

4

Is there a language that implements it this way?

I actually don’t much like it, most of my functions are fairly small and I actually like it the way it is.

If you are using an IDE or editor it is easy to collapse the function if it is not what you want to focus on.

···

On 2016-02-07, at 21:32:19, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
   print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
   print(“x=\(x), y=\(y)")
}

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

5

Is there a language that implements it this way?

I actually don’t much like it, most of my functions are fairly small and I actually like it the way it is.

If you are using an IDE or editor it is easy to collapse the function if it is not what you want to focus on.

Another problem with nested functions is that the indentation keeps increasing thus leaving less room for the code. This proposal also avoids that problem.

···

On Feb 7, 2016, at 9:57 AM, Craig Cruden <ccruden@novafore.com> wrote:

On 2016-02-07, at 21:32:19, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
  print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
  print(“x=\(x), y=\(y)")
}

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

6

I don’t think this fits well in the current design of Swift. It reminds me a lot of (Obj-)C-style headers, which Swift abandoned.

The nested function bodies would need to occur in the same file.

···

On Feb 7, 2016, at 10:00 AM, Alex Hoppen <alex@ateamer.de> wrote:

- Alex

On 07 Feb 2016, at 15:32, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
  print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
  print(“x=\(x), y=\(y)")
}

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

7

IMHO, that seems like more of an editor issue than a language issue.

···

Sent from my iPhone

On Feb 7, 2016, at 06:59, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

Another problem with nested functions is that the indentation keeps increasing thus leaving less room for the code. This proposal also avoids that problem.

8

If indentation is a big problem …. either you have a very small monitor, or you may have too much conditional code :p

If your functions are concise and you don’t create big spaghetti conditional code - I would not think indentation would be a great problem.

Usually I create functions inside functions for duplicate code within that function — and even without that de-duplication a function should not be too large, so once you reduplicate the code should be …. pretty short.

···

On 2016-02-07, at 21:59:43, Amir Michail <amichail@gmail.com> wrote:

On Feb 7, 2016, at 9:57 AM, Craig Cruden <ccruden@novafore.com> wrote:

Is there a language that implements it this way?

I actually don’t much like it, most of my functions are fairly small and I actually like it the way it is.

If you are using an IDE or editor it is easy to collapse the function if it is not what you want to focus on.

Another problem with nested functions is that the indentation keeps increasing thus leaving less room for the code. This proposal also avoids that problem.

On 2016-02-07, at 21:32:19, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
print(“x=\(x), y=\(y)")
}

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

9

If indentation is a big problem …. either you have a very small monitor, or you may have too much conditional code :p

If your functions are concise and you don’t create big spaghetti conditional code - I would not think indentation would be a great problem.

Nested functions allow you to reduce the length of parameter lists. And so you may end up with a very long function containing many nested functions while trying to reduce parameter list size.

···

On Feb 7, 2016, at 10:04 AM, Craig Cruden <ccruden@novafore.com> wrote:

Usually I create functions inside functions for duplicate code within that function — and even without that de-duplication a function should not be too large, so once you reduplicate the code should be …. pretty short.

On 2016-02-07, at 21:59:43, Amir Michail <amichail@gmail.com> wrote:

On Feb 7, 2016, at 9:57 AM, Craig Cruden <ccruden@novafore.com> wrote:

Is there a language that implements it this way?

I actually don’t much like it, most of my functions are fairly small and I actually like it the way it is.

If you are using an IDE or editor it is easy to collapse the function if it is not what you want to focus on.

Another problem with nested functions is that the indentation keeps increasing thus leaving less room for the code. This proposal also avoids that problem.

On 2016-02-07, at 21:32:19, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
print(“x=\(x), y=\(y)")
}

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

10

If indentation is a big problem …. either you have a very small monitor, or you may have too much conditional code :p

If your functions are concise and you don’t create big spaghetti conditional code - I would not think indentation would be a great problem.

Nested functions allow you to reduce the length of parameter lists. And so you may end up with a very long function containing many nested functions while trying to reduce parameter list size.

An other way to reduce parameter list and nested function is to define a class (or struct) that declare the parameters as ivar, and the netted function that have to be split as methods.

···

Le 7 févr. 2016 à 16:06, Amir Michail via swift-evolution <swift-evolution@swift.org> a écrit :

On Feb 7, 2016, at 10:04 AM, Craig Cruden <ccruden@novafore.com> wrote:

Usually I create functions inside functions for duplicate code within that function — and even without that de-duplication a function should not be too large, so once you reduplicate the code should be …. pretty short.

On 2016-02-07, at 21:59:43, Amir Michail <amichail@gmail.com> wrote:

On Feb 7, 2016, at 9:57 AM, Craig Cruden <ccruden@novafore.com> wrote:

Is there a language that implements it this way?

I actually don’t much like it, most of my functions are fairly small and I actually like it the way it is.

If you are using an IDE or editor it is easy to collapse the function if it is not what you want to focus on.

Another problem with nested functions is that the indentation keeps increasing thus leaving less room for the code. This proposal also avoids that problem.

On 2016-02-07, at 21:32:19, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

The problem with nested functions is that they can make the function containing them very long and hard to read.

So the idea is to separate the body of a nested function from where it is declared.

For example:

func f() {
var x:Int
func g(y:String) {
print(“x=\(x), y=\(y)")
}
...
}

could be refactored as:

func f() {
var x:Int
func g(y:String) // function body elsewhere to avoid clutter in f
...
}

func f().g(y:String) {
print(“x=\(x), y=\(y)")
}

_______________________________________________
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

11

I don’t believe this thread is well-served by having anyone be told why nested functions should not be nested functions.

Now, the power of nesting won’t be fully realized until nested protocol extensions work. The majority of my nested functions are generic (much thanks to those behind 7.3’s compiler improvements for allowing me to bring a lot of those back into functions, when I had had to move them outwards.), and would be better served as extensions on a nested protocol. But, I still use nested structs, classes, functions, and computed properties a lot; they can be very good for limiting scope to exactly what is needed, and for eliminating duplicate code.

So while I love the reasoning behind this proposal – the feature must be implemented, to avoid the ugliness that we deal with currently– I don’t like it as-is. I think the Swiftest way to do this is to use extensions for functions/properties/initializers.

I wager that initializers would benefit most:
http://merowing.info/2015/11/swift-init/

extension init(coreDataStack stack: CoreDataStack) {…