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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to