[Issue 8106] func.stringof with default args

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8106



--- Comment #12 from Walter Bright <bugzilla at digitalmars.com> 2012-06-14 07:14:50 PDT ---
(In reply to comment #11)
> (In reply to comment #7)
> > I.e. the default argument is propagated to the tuple. Will that work for you?
> 
> That would be amazing, though the argument names are equally important too.
> I'm pretty sure someone already had a pull request somewhere to add a __traits
> for the arg names.

I looked, but didn't see it.

> > pragma(msg, typeof(bar));
> > pragma(msg, PT[1]);
> It's not clear to me what those pragma's would produce.

They're just informative.

> 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 reply to comment #10)
> > I think that's a better solution, so I'm marking this as "won't fix".
> 
> I agree, although perhaps you shouldn't mark this as won't-fix, since I think
> it's still somewhat of a bug. Just drop the priority?
> func.stringof ideally shouldn't produce a syntactically incorrect string
> regardless.

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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------