[swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

[Jonathan Hull]

I would use this all the time if it was available.  What I do now most of the time is take an optional instead and then ‘??’ with the instance variable. That doesn’t work if I need an optional for other reasons, and nil is kind of a magical value…

Thanks,
Jon

> On Feb 22, 2017, at 11:53 AM, Nate Cook via swift-evolution <swift-evolution at swift.org> wrote:
> 
> After further examination, it looks like default parameter values are evaluated in a type context, not an instance context, which is why this isn't working. Using the instance context there would be provide more flexibility, since we could still explicitly access type-level vars.
> 
> Does anyone have a sense of how frequently type-level expressions are used in default parameters? As far as I've seen the standard library only uses literals. A change to this behavior would be source-breaking, but perhaps not painfully so.
> 
> Nate
> 
> 
>> On Feb 22, 2017, at 12:16 PM, Nate Cook via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello all,
>> 
>> I was surprised to find that I can't use an instance member as the default value of a method parameter, only constants and the run-time calculated #file, #line, etc. Is it possible to remove this limitation?
>> 
>> I'd like to propose that we add an overload of the collection index(_:offsetBy:) methods that use the collection's startIndex as a default parameter, but we can't provide that without either this feature or an extra overload. If the declaration looks like this:
>> 
>> extension Collection {
>>     func index(_ i: Index = startIndex, offsetBy n: IndexDistance) -> Index {
>>         // ...
>>     }
>> }
>> 
>> then calling that method with an omitted first parameter would treat it as something like this:
>> 
>> extension Collection {
>>     func index(offsetBy n: IndexDistance) -> Index {	
>>         let i = startIndex
>>         // ...
>>     }
>> }
>> 
>> Is this just syntactic sugar, or am I missing something that makes this harder than it looks? I can see how more complex expressions could be useful there, too, and can't find an obvious reason we couldn't use any code that could be inserted at the top of the method body.
>> 
>> Thanks!
>> Nate
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/6ac61278/attachment.html>