[swift-evolution] Proposal: Allow operators to have parameters with default values

[Eric Summers]

Yeah.  There are so many pitfalls to passing parameters implicitly.  It only works for exceptions because the function is annotated with throws.

Eric

> On Nov 2, 2017, at 10:05 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> I think the use case is legitimate, but I'm uncomfortable with the proposed solution. Firstly, because for the proposed use case it's not a "default" parameter in that it's not overridable: you can't actually pass another argument. Secondly, because you wouldn't want the two parameters of an infix operator function, or the single parameter of a non-infix operator function, to allow a default value (that totally gums up the distinction between prefix, infix, and postfix operators). I agree with Eric that the use case feels like it calls for a "macro-like" solution.
> 
> On Thu, Nov 2, 2017 at 7:50 PM, Eric Summers via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think this makes more sense as part of a hygienic macro system.  These “hidden” parameters could be made available to standard functions using some sort of convention to exclude them from autocompletion.
> 
> Eric
> 
> 
>> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171102/42e876ed/attachment.html>