[Issue 10193] Template args to UDA's
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue May 28 16:56:58 PDT 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10193
Manu <turkeyman at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #2 from Manu <turkeyman at gmail.com> 2013-05-28 16:56:57 PDT ---
(In reply to comment #1)
> Based on the current D language spec, prefix attribute is just rewritten to
> blocked attribute.
>
> @attribute("target", T) void func(string T)() {}
>
> to:
> @attribute("target", T) { void func(string T)() {} }
>
> And block attribute can contain other declarations.
>
> @attribute("target", T) {
>
> enum str = T.stringof;
>
> void func(string T)() {}
> }
>
> Well, if the enhancement is implemented, T would be deduced by the each call of
> template function foo. Then the enum value would become undeterministic.
>
> I think it is not implementable.
I see. Although I wonder if this is what users would expect. It seems more like
an implementation detail.
I would assume a very distinct difference between:
@attribute("target", T) void func(string T)() {}
@attribute("target", T) { ...stuff... void func(string T)() {} ...stuff... }
The obvious outer scope being the difference.
In the first case, it is all (or appears to be) one declaration, and T should
be usable across the declaration.
In the second, there is clearly an outer scope, and no sane programmer would
expect that you should be able to access arguments to an inner declaration
within the outer scope.
So I guess the question becomes, does the lowering of attributes to a scoped
attribute actually make sense anymore with the possibility of UDA's?
It never mattered before since no hard attributes received arguments, but times
are different now...
The behaviour is no longer transparent, and kinda counter-intuitive.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list