www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template args to UDA's

reply Manu <turkeyman gmail.com> writes:
--089e013cc39618c7b004ddc76ce8
Content-Type: text/plain; charset=UTF-8

So I've run into an expression I need to be able to implement std.simd
properly for GDC/LDC.

Doesn't work:
   attribute("target", T) void func(string T)(...);

In this case, currently, the UDA can't receive the template arg that was
given to the function.

I require that attributes on templates be able to make use of the template
args, since the template arg given may affect the attribute in some
circumstances.

--089e013cc39618c7b004ddc76ce8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So I&#39;ve run into an expression I need to be able to im=
plement std.simd properly for GDC/LDC.<div><br></div><div style>Doesn&#39;t=
 work:</div><div style>=C2=A0  attribute(&quot;target&quot;, T) void func(s=
tring T)(...);</div>
<div style><br></div><div style>In this case, currently, the UDA can&#39;t =
receive the template arg that was given to the function.</div><div style><b=
r></div><div style>I require that attributes on templates be able to make u=
se of the template args, since the template arg given may affect the attrib=
ute in some circumstances.</div>
</div>

--089e013cc39618c7b004ddc76ce8--
May 28 2013
next sibling parent "Diggory" <diggsey googlemail.com> writes:
On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:
 So I've run into an expression I need to be able to implement 
 std.simd
 properly for GDC/LDC.

 Doesn't work:
    attribute("target", T) void func(string T)(...);

 In this case, currently, the UDA can't receive the template arg 
 that was
 given to the function.

 I require that attributes on templates be able to make use of 
 the template
 args, since the template arg given may affect the attribute in 
 some
 circumstances.

Can you not move the template outside the attribute like this?: template func(string T) { attribute("target", T) void func(...); }
May 28 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2d682d3039204ddd1052c
Content-Type: text/plain; charset=UTF-8

On 29 May 2013 10:46, Diggory <diggsey googlemail.com> wrote:

 On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:

 So I've run into an expression I need to be able to implement std.simd
 properly for GDC/LDC.

 Doesn't work:
    attribute("target", T) void func(string T)(...);

 In this case, currently, the UDA can't receive the template arg that was
 given to the function.

 I require that attributes on templates be able to make use of the template
 args, since the template arg given may affect the attribute in some
 circumstances.

Can you not move the template outside the attribute like this?: template func(string T) { attribute("target", T) void func(...); }

Yes, that's Kenji's initial suggestion, which I can use for now, but it feels like a workaround. It feels pretty lame to have to wrap select functions in an arbitrary outer scope, and it also has some subtle implications; how does auto-complete/intellisense see it? As a template, or as whatever it resolves to? The latter would imply some pretty powerful semantic analysis, and if there's static logic inside the template? The IDE basically won't work properly for any of these functions. Either way, the attribute certainly looks like it's part of the declaration, I think any reasoning programmer would assume that it is. It's only a DMD implementation detail that says otherwise, and it's not particularly intuitive to a programmer. --001a11c2d682d3039204ddd1052c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 29 May 2013 10:46, Diggory <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:diggsey googlemail.com" target=3D"_blank">diggsey googlemail.co= m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q= uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"> <div class=3D"im">On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> So I&#39;ve run into an expression I need to be able to implement std.simd<= br> properly for GDC/LDC.<br> <br> Doesn&#39;t work:<br> =C2=A0 attribute(&quot;target&quot;, T) void func(string T)(...);<br> <br> In this case, currently, the UDA can&#39;t receive the template arg that wa= s<br> given to the function.<br> <br> I require that attributes on templates be able to make use of the template<= br> args, since the template arg given may affect the attribute in some<br> circumstances.<br> </blockquote> <br></div> Can you not move the template outside the attribute like this?:<br> <br> template func(string T) {<br> =C2=A0 =C2=A0 attribute(&quot;target&quot;, T) void func(...);<br> }<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>Yes, that&#39= ;s Kenji&#39;s initial suggestion, which I can use for now, but it feels li= ke a workaround.</div><div class=3D"gmail_extra" style>It feels pretty lame= to have to wrap select functions in an arbitrary outer scope, and it also = has some subtle implications; how does auto-complete/intellisense see it? A= s a template, or as whatever it resolves to?</div> <div class=3D"gmail_extra" style>The latter would imply some pretty powerfu= l semantic analysis, and if there&#39;s static logic inside the template? T= he IDE basically won&#39;t work properly for any of these functions.</div> <div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
Either way, the attribute certainly looks like it&#39;s part of the declar=

nly a DMD implementation detail that says otherwise, and it&#39;s not parti= cularly intuitive to a programmer.</div> </div> --001a11c2d682d3039204ddd1052c--
May 28 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--e89a8f642b58f5c07f04ddd1297e
Content-Type: text/plain; charset=UTF-8

2013/5/29 Manu <turkeyman gmail.com>

 Either way, the attribute certainly looks like it's part of the
 declaration, I think any reasoning programmer would assume that it is. It's
 only a DMD implementation detail that says otherwise, and it's not
 particularly intuitive to a programmer.

It's not a dmd implementation detail. It is part of current D language design. dmd works as well. No bug there, so this is definitely an enhancement. But I can agree that is a little not good from human sense. I know a related issue. struct S { immutable int foo() {} // immutable is prefix attribute (==storage class) } In above, `immutable` would be applied to the declaration `foo`, not its return type `int`. But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first. Kenji Hara --e89a8f642b58f5c07f04ddd1297e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /5/29 Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:turkeyman gmail.com" tar= get=3D"_blank">turkeyman gmail.com</a>&gt;</span><br><blockquote class=3D"g= mail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg= in-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord= er-left-style:solid;padding-left:1ex"> <div dir=3D"ltr"><div><div class=3D"h5">Either way, the attribute certainly= looks like it&#39;s part of the declaration, I think any reasoning program= mer would assume that it is. It&#39;s only a DMD implementation detail that= says otherwise, and it&#39;s not particularly intuitive to a programmer.<b= r> </div></div> </div> </blockquote></div><br></div><div class=3D"gmail_extra">It&#39;s not a dmd = implementation detail. It is part of current D language design. dmd works a= s well. No bug there, so this is definitely an enhancement.</div><div class= =3D"gmail_extra"> <br></div><div class=3D"gmail_extra">But I can agree that is a little not g= ood from human sense. I know a related issue.</div><div class=3D"gmail_extr= a"><br></div><div class=3D"gmail_extra">struct S {</div><div class=3D"gmail= _extra"> =C2=A0 =C2=A0 immutable int foo() {} =C2=A0 =C2=A0// immutable is prefix at= tribute (=3D=3Dstorage class)</div><div class=3D"gmail_extra">}</div><div c= lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In above, `immuta= ble` would be applied to the declaration `foo`, not its return type `int`.<= /div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But, changi= ng semantics would break much existing code. Your enhancement belongs same = area. We need to get agreement of D programmers first.</div><div class=3D"g= mail_extra"> <br></div><div class=3D"gmail_extra">Kenji Hara</div></div> --e89a8f642b58f5c07f04ddd1297e--
May 28 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c32dfe39836e04ddd14bef
Content-Type: text/plain; charset=UTF-8

On 29 May 2013 11:18, Kenji Hara <k.hara.pg gmail.com> wrote:

 2013/5/29 Manu <turkeyman gmail.com>

 Either way, the attribute certainly looks like it's part of the
 declaration, I think any reasoning programmer would assume that it is. It's
 only a DMD implementation detail that says otherwise, and it's not
 particularly intuitive to a programmer.

It's not a dmd implementation detail. It is part of current D language design. dmd works as well. No bug there, so this is definitely an enhancement. But I can agree that is a little not good from human sense. I know a related issue. struct S { immutable int foo() {} // immutable is prefix attribute (==storage class) } In above, `immutable` would be applied to the declaration `foo`, not its return type `int`. But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first.

Yeah, that's a good point, I've never liked that ambiguity. I always write: immutable(int) foo() {} Otherwise I never really know what to expect. --001a11c32dfe39836e04ddd14bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 29 May 2013 11:18, Kenji Hara <span dir=3D"ltr">&lt;<a = href=3D"mailto:k.hara.pg gmail.com" target=3D"_blank">k.hara.pg gmail.com</= a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot= e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"><div class=3D"im"><div class=3D"gmail_extra"><div class=3D= "gmail_quote">2013/5/29 Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:turkey= man gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt;</span><br><blo= ckquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;marg= in-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb= (204,204,204);border-left-style:solid;padding-left:1ex"> <div dir=3D"ltr"><div><div>Either way, the attribute certainly looks like i= t&#39;s part of the declaration, I think any reasoning programmer would ass= ume that it is. It&#39;s only a DMD implementation detail that says otherwi= se, and it&#39;s not particularly intuitive to a programmer.<br> </div></div> </div> </blockquote></div><br></div></div><div class=3D"gmail_extra">It&#39;s not = a dmd implementation detail. It is part of current D language design. dmd w= orks as well. No bug there, so this is definitely an enhancement.</div><div= class=3D"gmail_extra"> <br></div><div class=3D"gmail_extra">But I can agree that is a little not g= ood from human sense. I know a related issue.</div><div class=3D"gmail_extr= a"><br></div><div class=3D"gmail_extra">struct S {</div><div class=3D"gmail= _extra"> =C2=A0 =C2=A0 immutable int foo() {} =C2=A0 =C2=A0// immutable is prefix at= tribute (=3D=3Dstorage class)</div><div class=3D"gmail_extra">}</div><div c= lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In above, `immuta= ble` would be applied to the declaration `foo`, not its return type `int`.<= /div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But, changi= ng semantics would break much existing code. Your enhancement belongs same = area. We need to get agreement of D programmers first.</div></div></blockqu= ote> <div><br></div><div style>Yeah, that&#39;s a good point, I&#39;ve never lik= ed that ambiguity.</div><div style>I always write: immutable(int) foo() {}<= /div><div style>Otherwise I never really know what to expect.</div></div> </div></div> --001a11c32dfe39836e04ddd14bef--
May 28 2013
prev sibling next sibling parent "Diggory" <diggsey googlemail.com> writes:
 Yes, that's Kenji's initial suggestion, which I can use for

Ah, didn't see it because the forum keeps breaking threads up into little pieces...
May 28 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 May 2013 21:08:42 -0400, Manu <turkeyman gmail.com> wrote:

 On 29 May 2013 10:46, Diggory <diggsey googlemail.com> wrote:

 Can you not move the template outside the attribute like this?:

 template func(string T) {
      attribute("target", T) void func(...);
 }

Yes, that's Kenji's initial suggestion, which I can use for now, but it feels like a workaround. It feels pretty lame to have to wrap select functions in an arbitrary outer scope, and it also has some subtle implications; how does auto-complete/intellisense see it? As a template, or as whatever it resolves to?

It's not a workaround, nor arbitrary. In fact: func(string T)(...) is EXACTLY equivalent to: template func(string T) { func(...) } The compiler implicitly converts the former to the latter. In fact, the formal name of func!"foo"() is func!"foo".func() in both cases.
 The latter would imply some pretty powerful semantic analysis, and if
 there's static logic inside the template? The IDE basically won't work
 properly for any of these functions.

Any conditional compilation breaks IFTI. This is required, since the "magic" of IFTI means it must partially instantiate the template to see whether the function parameters match. It could very easily get stuck in the weeds through some arbitrary conditional compilation.
 Either way, the attribute certainly looks like it's part of the
 declaration, I think any reasoning programmer would assume that it is.  
 It's
 only a DMD implementation detail that says otherwise, and it's not
 particularly intuitive to a programmer.

On this, I agree. But it is important to remember that a function template is first a template and then a function. When you apply attributes to it, you are applying it to the outer-most piece -- the template. And IATI (implicit attribute template instantiation) isn't available yet :) I think it's awesome that IFTI handles this messy detail, and it would be nice if uda's were part of that messy detail. -Steve
May 28 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 29, 2013 11:28:06 Manu wrote:
 On 29 May 2013 11:18, Kenji Hara <k.hara.pg gmail.com> wrote:
 But I can agree that is a little not good from human sense. I know a
 related issue.
 
 struct S {
 
 immutable int foo() {} // immutable is prefix attribute (==storage
 
 class)
 }
 
 In above, `immutable` would be applied to the declaration `foo`, not its
 return type `int`.
 
 But, changing semantics would break much existing code. Your enhancement
 belongs same area. We need to get agreement of D programmers first.

Yeah, that's a good point, I've never liked that ambiguity. I always write: immutable(int) foo() {} Otherwise I never really know what to expect.

Well, it's not actually ambiguous at all. It's just undesirable. If the const, immutable, or inout uses parens around the return type, then it's the return type which is const, immutable, or inout. In all other cases, it's the function (and thus the this pointer). So, it's completely clear if you know the rules, but the rules suck. Unfortunately, if function attributes which could affect the return type could only go on the right (as is the case with C++), then those function attributes would be inconsistent with the others, and Walter doesn't like that. Enforcing that all function attributes always go on the right would fix that, but I expect that that's too different from C++, Java, etc. for that to have ever been acceptable, and at this point, it would break too much code for Walter to agree to change it. - Jonathan M Davis
May 28 2013