Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

> On Dec 28, 2015, at 12:29 PM, Matthew Johnson wrote: > > > > Sent from my iPhone > > On Dec 28, 2015, at 2:04 PM, Joe Groff > wrote: > >> >>> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution >>>

[swift-evolution] [Pitch] Option parameters (potential resilience advantages)

I've had an idea floating around in my mind for a couple weeks now and would like to find out what others think about it. The basic idea is really simple. It introduces an `@option` parameter attribute. Parameters with this attribute would behave like parameters with a default value at the

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

The current workaround is to add an overload that calls the "main" version: > class Foo { > // version 1 > func foo() { > print(5) > } > > // version 2 > func foo() { > foo(5) > } > > func foo(value: Int) { >

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

> On Dec 28, 2015, at 1:08 PM, Félix Cloutier wrote: > > The current workaround is to add an overload that calls the "main" version: > >> class Foo { >> // version 1 >> func foo() { >> print(5) >> } >> >> // version 2 >> func foo()

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Dec 28, 2015, at 1:39 PM, Stephen Celis wrote: >> >> I'm not sure I understand the use case. Aren't these optimizations that >> could be better handled

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

Sent from my iPhone > On Dec 28, 2015, at 2:04 PM, Joe Groff wrote: > > >>> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Dec 28, 2015, at 1:39 PM, Stephen Celis wrote: