While I agree that I can’t think of another use-case off the top of my head (curried operators, somehow? Maybe?), I also don’t necessarily see the benefit of restricting it.
As the implementation currently stands, we could add new keywords, like #module or #context (which would capture #file, #line, #function, #module, etc as a single type), without having to change the implementation of IsBinaryOperator() and IsUnaryOperator(). It’s also nice that if a legit use-case ever did come up, the language would support it out-of-the-box without requiring another change. Dave > On Nov 2, 2017, at 6:34 PM, Tony Allevato <[email protected]> wrote: > > I like this idea as it's presented here, for the debugging/logging reasons > that you stated. > > Should we tighten the shackles a little be to validate that *only* the > special #file/#line/#function directives can be permitted for these extra > parameters? I'm struggling to think of a case where we would want to allow > something else, since there's no way to provide the values for them in a > standard call. > > > On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Hi SE, > > As I’ve been using my own custom operators like “?!”, “!!”, or operators > provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file > and #line where the operators are used to make debugging their use a lot > easier. > > For example, given something the unwrap-or-die operator > (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/XXXX-unwrap-or-die.md > > <https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/XXXX-unwrap-or-die.md>), > you’d want to capture the #file and #line so you could pass it on to the > underlying call to fatalError(). > > Or, if you’re using a custom bind operator and something goes wrong, it’d be > great to be able to capture the file and line where the operator is used so > you can quickly triage the bug in your code. > > Unfortunately, Swift has the hard limit the the implementations of unary > operators may have one-and-only-one parameter, and that binary operators may > only have two parameters. > > I’d like to propose a very minor change to Swift, whereby operator > implementations may have more than their one or two parameters, provided that > all subsequent parameters come with a default value. This would make it > trivial to add in #file, #line, #function, etc to your operator > implementations, which you can then capture for your own purposes. > > An implementation of this change, with passing tests, can be found here: > https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697 > > <https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697> > > Dave > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
