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 > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
