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

[Xiaodi Wu]

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> 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> 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> 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),
>> 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/c65c634a59b63add0dc9df1ac8803e
>> 9d70bfa697
>>
>> Dave
>> _______________________________________________
>> swift-evolution mailing list
>> 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
>
>
>
> _______________________________________________
> 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/20171102/47de4a03/attachment.html>