Make the first parameter in a function declaration follow the same rules as the others


(Ted van Gaalen) #1

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

Because you always have to specify parameter names/labels
it is easy to see (for the compiler) which parameters
are omitted.

Omitting a parameter for which no default value was
specified is still an error.

The confusing # and _ are no longer necessary.

‘inout’ and external and local parameter names behavior remain as they are.

like so

     func foo(inout a: Type, b: Type = 12.34, c: Type) // b may be omitted
or
     func foo(a alocal: Type, b blocal: Type = 12.34, c: Type= 3.14159) // b and c may be omitted

Valid calls:
    
    foo(a: v1, b: v2, c: v3) // in sequence
    foo(c: v3, a: v1, b: v3) // arbitrary parameter sequence is allowed.

    foo(c: v13) // parms a and b are not present: default values wil be taken
                                   // or error if no default specified.

Allow for more than 1 variadic parameter, why is this currently limited to one variadic parameter only?
    
    foo(a: Type, b:Type…, c: Type…,d: Type)

   foo(v1,b: v2,c: v3) // this is an error: parameter name missing with first parameter.
          
It would end the confusion.

TedvG


(Ted van Gaalen) #2

if parameter names are obligatory, one could
remove the commas completely in the function call:

     foo(a: v1 b: 123.45 c: qwertyuiop)

or alternatively with commas only:

     foo( a v1, b 123.45, c 12 * 3 + 2)

TedvG

···

Subject: Make the first parameter in a function declaration follow the same rules as the others

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

Because you always have to specify parameter names/labels
it is easy to see (for the compiler) which parameters
are omitted.

Omitting a parameter for which no default value was
specified is still an error.

The confusing # and _ are no longer necessary.

‘inout’ and external and local parameter names behavior remain as they are.

like so

    func foo(inout a: Type, b: Type = 12.34, c: Type) // b may be omitted
or
    func foo(a alocal: Type, b blocal: Type = 12.34, c: Type= 3.14159) // b and c may be omitted

Valid calls:

   foo(a: v1, b: v2, c: v3) // in sequence
   foo(c: v3, a: v1, b: v3) // arbitrary parameter sequence is allowed.

   foo(c: v13) // parms a and b are not present: default values wil be taken
                                  // or error if no default specified.

Allow for more than 1 variadic parameter, why is this currently limited to one variadic parameter only?

   foo(a: Type, b:Type…, c: Type…,d: Type)

  foo(v1,b: v2,c: v3) // this is an error: parameter name missing with first parameter.

It would end the confusion.

TedvG


(Haravikk) #3

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

  func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

  func insert(element:Element) { … }
  func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.

···

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.


(Ted van Gaalen) #4

( didn’t know it was on its way, so much to read here, missing things at times:

n.b. I’ve just read proposal SE-0046,
"Establish consistent label behavior across all parameters including first labels”
Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)

To Jake and Erica:
      Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.

···

------------

Thank you Haravikk,
but I’d prefer to have a label obligatory on the first parm as well, for consistency,
simplicity and readability.
Also for clarity:
     A parameter name should not be part of a function name.

As in your second example:

  func insert( element: Element ) { … }
  func insert( contentsOf: Sequence) { … }

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

         func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators

or formatted like this for clarity :

         func insert( element: Book
                              reorderBy: .authorName
                   dropOldVersions: true ) -> Bool
         { … }

coincidentally, notice this is like in ObjC.. (which i liked)

It also makes the logic with omitted default parameter simpler.
and would allow an arbitrary parameter sequence in the call, if needed.

(i've appended this possibility later)

I prefer overloading functions in this kind of cases instead of:

   insertBook(...
   insertBooks(...
   insertBooksFromArray(...

but maybe that’s just my personal taste.

At the moment I can’t find conflicts with any other language construct,
also for a new parameter list format without commas,
does anyone?

TedvG

On 12.03.2016, at 19:22, Haravikk <swift-evolution@haravikk.me> wrote:

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

  func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

  func insert(element:Element) { … }
  func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.


(Ted van Gaalen) #5

oops !! Errata:
in my examples something went wrong: here they are again, corrected:

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

        bookList.insert( element: book reorderBy: .authorName dropOldVersions: true) // no comma separators

or formatted like this for clarity :

        bookList.insert( element: book
                                   reorderBy: .authorName
                         dropOldVersions: true )
      
Sorry
TedvG

TedvG

···

On 12.03.2016, at 20:18, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

( didn’t know it was on its way, so much to read here, missing things at times:

n.b. I’ve just read proposal SE-0046,
"Establish consistent label behavior across all parameters including first labels”
Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)

To Jake and Erica:
     Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.

------------

Thank you Haravikk,
but I’d prefer to have a label obligatory on the first parm as well, for consistency,
simplicity and readability.
Also for clarity:
    A parameter name should not be part of a function name.

As in your second example:

  func insert( element: Element ) { … }
  func insert( contentsOf: Sequence) { … }

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

        func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators

or formatted like this for clarity :

        func insert( element: Book
                             reorderBy: .authorName
                  dropOldVersions: true ) -> Bool
        { … }

coincidentally, notice this is like in ObjC.. (which i liked)

It also makes the logic with omitted default parameter simpler.
and would allow an arbitrary parameter sequence in the call, if needed.

(i've appended this possibility later)

I prefer overloading functions in this kind of cases instead of:

  insertBook(...
  insertBooks(...
  insertBooksFromArray(...

but maybe that’s just my personal taste.

At the moment I can’t find conflicts with any other language construct,
also for a new parameter list format without commas,
does anyone?

TedvG

On 12.03.2016, at 19:22, Haravikk <swift-evolution@haravikk.me> wrote:

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

  func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

  func insert(element:Element) { … }
  func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.


(Pierre Monod-Broca) #6

I'm not for mandatory parameter names, it doesn't always make sense to have them. Besides I don't see much value in removing the commas or reordering the parameters.

By the way how would you do for variadics parameters ?

Pierre

···

Le 12 mars 2016 à 21:18, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> a écrit :

oops !! Errata:
in my examples something went wrong: here they are again, corrected:

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

       bookList.insert( element: book reorderBy: .authorName dropOldVersions: true) // no comma separators

or formatted like this for clarity :

       bookList.insert( element: book
                                  reorderBy: .authorName
                        dropOldVersions: true )

Sorry
TedvG

TedvG

On 12.03.2016, at 20:18, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

( didn’t know it was on its way, so much to read here, missing things at times:

n.b. I’ve just read proposal SE-0046,
"Establish consistent label behavior across all parameters including first labels”
Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)

To Jake and Erica:
    Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.

------------

Thank you Haravikk,
but I’d prefer to have a label obligatory on the first parm as well, for consistency,
simplicity and readability.
Also for clarity:
   A parameter name should not be part of a function name.

As in your second example:

   func insert( element: Element ) { … }
   func insert( contentsOf: Sequence) { … }

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

       func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators

or formatted like this for clarity :

       func insert( element: Book
                            reorderBy: .authorName
                 dropOldVersions: true ) -> Bool
       { … }

coincidentally, notice this is like in ObjC.. (which i liked)

It also makes the logic with omitted default parameter simpler.
and would allow an arbitrary parameter sequence in the call, if needed.

(i've appended this possibility later)

I prefer overloading functions in this kind of cases instead of:

insertBook(...
insertBooks(...
insertBooksFromArray(...

but maybe that’s just my personal taste.

At the moment I can’t find conflicts with any other language construct,
also for a new parameter list format without commas,
does anyone?

TedvG

On 12.03.2016, at 19:22, Haravikk <swift-evolution@haravikk.me> wrote:

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

   func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

   func insert(element:Element) { … }
   func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.

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


(Ted van Gaalen) #7

Variadic parameters? That’s very easy:

                                                                           // in this example, a: b: c: and d: are parameter names/labels

   fooVariadics( a: thing // Easy to parse: the colon : always signifies it is a label, not a var/value
                         b: 12,45, 65, 56, 456 // b and c are variadic. .
                         c: “aeroplane”, ”car”, ”rocket” // The commas in-between the variadic values are not interpreted as parameter separators.
                         d: temperature )

This would work too: (different parameter sequence if you’d prefer to have the variadic parameters (optically) at the end,
                                     in spite of the sequence with which they are declared in the function declaration.)

   fooVariadics( a: thing // Parameter sequence can be arbitrary.
                         d: temperature )
                         c: “boat”, ”car”, ”rocket” // Note that a trailing comma behind a variadic row would attempt to include the next parameter label
                         b: 12,45, 65, 56, 456 ) // unless the compiler is a bit smart and sees the colon : of it: but it should raise a compile error in that case.

Two great advantages of this approach without commas would be:

-there is no obligation to put a variadic sequence at the end of the parameter list
-it is now possible to use mulitple variadic parameters.

Ain’t that cool?
TedvG

···

On 12.03.2016, at 22:17, Pierre Monod-Broca <pierremonodbroca@gmail.com> wrote:

I'm not for mandatory parameter names, it doesn't always make sense to have them. Besides I don't see much value in removing the commas or reordering the parameters.

By the way how would you do for variadics parameters ?

Pierre

Le 12 mars 2016 à 21:18, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> a écrit :

oops !! Errata:
in my examples something went wrong: here they are again, corrected:

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

      bookList.insert( element: book reorderBy: .authorName dropOldVersions: true) // no comma separators

or formatted like this for clarity :

      bookList.insert( element: book
                                 reorderBy: .authorName
                       dropOldVersions: true )

Sorry
TedvG

TedvG

On 12.03.2016, at 20:18, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

( didn’t know it was on its way, so much to read here, missing things at times:

n.b. I’ve just read proposal SE-0046,
"Establish consistent label behavior across all parameters including first labels”
Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)

To Jake and Erica:
   Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.

------------

Thank you Haravikk,
but I’d prefer to have a label obligatory on the first parm as well, for consistency,
simplicity and readability.
Also for clarity:
  A parameter name should not be part of a function name.

As in your second example:

  func insert( element: Element ) { … }
  func insert( contentsOf: Sequence) { … }

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

      func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators

or formatted like this for clarity :

      func insert( element: Book
                           reorderBy: .authorName
                dropOldVersions: true ) -> Bool
      { … }

coincidentally, notice this is like in ObjC.. (which i liked)

It also makes the logic with omitted default parameter simpler.
and would allow an arbitrary parameter sequence in the call, if needed.

(i've appended this possibility later)

I prefer overloading functions in this kind of cases instead of:

insertBook(...
insertBooks(...
insertBooksFromArray(...

but maybe that’s just my personal taste.

At the moment I can’t find conflicts with any other language construct,
also for a new parameter list format without commas,
does anyone?

TedvG

On 12.03.2016, at 19:22, Haravikk <swift-evolution@haravikk.me> wrote:

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

  func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

  func insert(element:Element) { … }
  func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.

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


(Ted van Gaalen) #8

arrhg! typo again! Closing parenthesis) removed in 2nd example from behind “temperature”, sorry

···

On 12.03.2016, at 22:51, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

Variadic parameters? That’s very easy:

                                                                          // in this example, a: b: c: and d: are parameter names/labels

  fooVariadics( a: thing // Easy to parse: the colon : always signifies it is a label, not a var/value
                        b: 12,45, 65, 56, 456 // b and c are variadic. .
                        c: “aeroplane”, ”car”, ”rocket” // The commas in-between the variadic values are not interpreted as parameter separators.
                        d: temperature )

This would work too: (different parameter sequence if you’d prefer to have the variadic parameters (optically) at the end,
                                    in spite of the sequence with which they are declared in the function declaration.)

  fooVariadics( a: thing // Parameter sequence can be arbitrary.
                        d: temperature
                        c: “boat”, ”car”, ”rocket” // Note that a trailing comma behind a variadic row would attempt to include the next parameter label
                        b: 12,45, 65, 56, 456 ) // unless the compiler is a bit smart and sees the colon : of it: but it should raise a compile error in that case.

Two great advantages of this approach without commas would be:

-there is no obligation to put a variadic sequence at the end of the parameter list
-it is now possible to use mulitple variadic parameters.

Ain’t that cool?
TedvG

On 12.03.2016, at 22:17, Pierre Monod-Broca <pierremonodbroca@gmail.com> wrote:

I'm not for mandatory parameter names, it doesn't always make sense to have them. Besides I don't see much value in removing the commas or reordering the parameters.

By the way how would you do for variadics parameters ?

Pierre

Le 12 mars 2016 à 21:18, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> a écrit :

oops !! Errata:
in my examples something went wrong: here they are again, corrected:

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

     bookList.insert( element: book reorderBy: .authorName dropOldVersions: true) // no comma separators

or formatted like this for clarity :

     bookList.insert( element: book
                                reorderBy: .authorName
                      dropOldVersions: true )

Sorry
TedvG

TedvG

On 12.03.2016, at 20:18, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

( didn’t know it was on its way, so much to read here, missing things at times:

n.b. I’ve just read proposal SE-0046,
"Establish consistent label behavior across all parameters including first labels”
Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)

To Jake and Erica:
  Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.

------------

Thank you Haravikk,
but I’d prefer to have a label obligatory on the first parm as well, for consistency,
simplicity and readability.
Also for clarity:
A parameter name should not be part of a function name.

As in your second example:

func insert( element: Element ) { … }
func insert( contentsOf: Sequence) { … }

Always specifying labels/names allows us also to have a simpler function syntax as well like so:

     func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators

or formatted like this for clarity :

     func insert( element: Book
                          reorderBy: .authorName
               dropOldVersions: true ) -> Bool
     { … }

coincidentally, notice this is like in ObjC.. (which i liked)

It also makes the logic with omitted default parameter simpler.
and would allow an arbitrary parameter sequence in the call, if needed.

(i've appended this possibility later)

I prefer overloading functions in this kind of cases instead of:

insertBook(...
insertBooks(...
insertBooksFromArray(...

but maybe that’s just my personal taste.

At the moment I can’t find conflicts with any other language construct,
also for a new parameter list format without commas,
does anyone?

TedvG

On 12.03.2016, at 19:22, Haravikk <swift-evolution@haravikk.me> wrote:

On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

When I started using Swift (on the whole a pleasant journey)
the most confusing thing to me was, and at times still is, the parameter list,

I would prefer:

-uniform for functions(…) AND init(…)
-every parameter must be used with its name/label. Always, no exceptions.
-no shortcuts.
-allow arbitrary parameter sequence.
which is possible and very easy to implement when you always have to use names.
-no trailing commas.

I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:

func insert(_ element:Element) { … }

No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.

In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:

func insert(element:Element) { … }
func insert(contentsOf:Sequence) { … }

But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.

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