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