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

Sent from my iPhone > On Dec 28, 2015, at 2:52 PM, Joe Groff wrote: > > >> 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-ev

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

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: >>> >>> I'm not sure I understand the use case. Aren't these optimizatio

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 by the compiler? Do we really want to provide hints

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() { >> f

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

> 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 by the compiler? Do we really want to provide hints like > these manually in our own libraries? Instead of `value: Int? = nil`, why not > `

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

I'm not sure I understand the use case. Aren't these optimizations that could be better handled by the compiler? Do we really want to provide hints like these manually in our own libraries? Instead of `value: Int? = nil`, why not `value: Int = 42`? Stephen > On Dec 28, 2015, at 11:11 AM, Matth

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) { >

[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 ca