<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.<div class=""><br class=""></div><div class="">Chris has mentioned in interviews that such a system is "a big feature that’s open-ended and requires a huge design process” which makes off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.</div><div class=""><br class=""></div><div class="">Personally I’d like to be able to better debug my apps in Swift 4.1 rather than waiting another 2 or 3 years for a magical macro system to somehow solve this.</div><div class=""><br class=""></div><div class="">Dave<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 6:50 PM, Eric Summers <<a href="mailto:eric_summers@icloud.com" class="">eric_summers@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Eric<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I like this idea as it's presented here, for the debugging/logging reasons that you stated.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Hi SE,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">For example, given something the unwrap-or-die operator (<a href="https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/XXXX-unwrap-or-die.md" target="_blank" class="">https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/XXXX-unwrap-or-die.md</a>), you’d want to capture the #file and #line so you could pass it on to the underlying call to fatalError().</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">An implementation of this change, with passing tests, can be found here: <a href="https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697" target="_blank" class="">https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697</a></div><div class=""><br class=""></div><div class="">Dave</div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>