The call stack could certainly be a worthwhile thing to capture in an operator implementation. The #file and #line would tell you which usage of the operator you’re using, and the callStackSymbols would tell you how you got there. You’d want them both, however, if you used the same custom operator multiple times in the calling function: the callStackSymbols alone wouldn’t necessarily be enough to disambiguate which usage of the operator you should be looking at.
Dave > On Nov 3, 2017, at 11:40 AM, Mike Kluev <mike.kl...@gmail.com> wrote: > > on Fri, 3 Nov 2017 09:40:35 -0600 Dave DeLong <sw...@davedelong.com > <mailto:sw...@davedelong.com>> wrote: > > > That’s cool, but a hygienic macro system isn’t anywhere on the Swift > > roadmap. > > > > 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. > > > 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. > > if that's just for debugging -- consider using Thread.callStackSymbols > > last i checked it has the entries in the mangled form, but probably it's (1) > good enough for debugging purposes and (2) possible to de-mangle them somehow. > > Mike >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
