http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #13 from Manu <turkey...@gmail.com> 2012-06-14 08:03:11 PDT --- (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #7) > > > pragma(msg, typeof(bar)); > > > pragma(msg, PT[1]); > > It's not clear to me what those pragma's would produce. > > They're just informative. What I mean is, I don't quite follow the syntax of your proposal. What would be the output of the pragmas you illustrate? Ie, what _exactly_ does PT contain? I just understand you intend that it will somehow contain the type AND default arg expression (but not the name?), rather than just the type as it does now... how does that work in practise syntactically? > > If I'm generating functions to wrap other functions, the new function has to > > have matching parameter names. If I use nonsense names, then auto-complete > > pop-ups will just show nonsense to the user, and the user wouldn't know what > > you're supposed to pass to the function. > > Ok, so it's a user-experience issue, not one where it does not work. Let me > think about it. It's important that I understand what issue you're trying to > solve. In this case, only that aspect (the names) is a UX issue, the rest is mechanical. The default args are required in the wrapper I generate or calling code won't compile. That said, I wouldn't be satisfied with the solution if I didn't have access to the names, and I would have to persist with tedious parsing FuncType.stringof to gather them again... There are other cases where I have needed the names too. In mixins inserted into a function body; without a trait that can give the argument names, there's no way to refer to function arguments from within the mixin. I have run in to this situations numerous times, but I've worked around them at the cost of code complexity since there was no solution at the time. I'm just saying, access to the parameter names is also important if you're going to the effort of being able to introspect the default arg expressions. > It doesn't produce a syntactically incorrect string, it produces one that > semantically won't compile in the context it is in. I reiterate that the > problem is which names are in scope and which aren't? It's just an impractical > problem, and making it work in one case will break others. It's a game of > whack-a-mole. I'd imagine that what should actually be expected, is the expression relative to the scope where it was declared. Ie, the expression as it was written in the declaration. Nothing else makes any sense by my logic. But this is obviously not particularly important. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
