www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: std.algorithm move() struct emptying

reply bearophile <bearophileHUGS lycos.com> writes:
Stanislav Blinov:


 Currently you can take its address, so doesn't that mean that it's an lvalue?



 No, you can't. Generally, that is.
 For example:
 enum A
 {
 	a,
 	b
 }
 
 void main()
 {
 	void* p = &A.init; // won't compile
 }
 
 You may be able to take address of what .init returns, but what Andrei 
 meant by 'it is not guaranteed' means that this is not always the case. 
 So basically, you should not rely on the cases when you can do that.



If in generic code T.init is not guaranteed to be an lvalue, as your example
shows, isn't it better to disallow (turning it into a syntax error) &T.init in
all cases?

Bye,
bearophile
Aug 31 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-31 06:16:17 -0400, bearophile <bearophileHUGS lycos.com> said:


 If in generic code T.init is not guaranteed to be an lvalue, as your 
 example shows, isn't it better to disallow (turning it into a syntax 
 error) &T.init in all cases?



Personally, I'd say the code should check if T.init is an lvalue using 
__traits(compiles, &T.init) or is(typeof(&T.init)) and avoid creating a 
static variable or temporary when it is. This optimization of course 
depends &T.init not being a syntax error.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Aug 31 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/10 7:49 CDT, Michel Fortin wrote:

 On 2010-08-31 06:16:17 -0400, bearophile <bearophileHUGS lycos.com> said:


 If in generic code T.init is not guaranteed to be an lvalue, as your
 example shows, isn't it better to disallow (turning it into a syntax
 error) &T.init in all cases?



 Personally, I'd say the code should check if T.init is an lvalue using
 __traits(compiles, &T.init) or is(typeof(&T.init)) and avoid creating a
 static variable or temporary when it is. This optimization of course
 depends &T.init not being a syntax error.



I recall I wrote that code to avoid a compiler bug when T == Tuple!(some 
types).

Andrei
Aug 31 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/10 11:28 CDT, Philippe Sigaud wrote:

 On Tue, Aug 31, 2010 at 17:05, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 8/31/10 7:49 CDT, Michel Fortin wrote:

         On 2010-08-31 06:16:17 -0400, bearophile
         <bearophileHUGS lycos.com <mailto:bearophileHUGS lycos.com>> said:

             If in generic code T.init is not guaranteed to be an lvalue,
             as your
             example shows, isn't it better to disallow (turning it into
             a syntax
             error) &T.init in all cases?


         Personally, I'd say the code should check if T.init is an lvalue
         using
         __traits(compiles, &T.init) or is(typeof(&T.init)) and avoid
         creating a
         static variable or temporary when it is. This optimization of course
         depends &T.init not being a syntax error.


     I recall I wrote that code to avoid a compiler bug when T ==
     Tuple!(some types).

     Andrei


 Is that related to this bug?
 http://d.puremagic.com/issues/show_bug.cgi?id=4536


 Philippe



Very possible.

Andrei
Aug 31 2010
prev sibling parent Stanislav Blinov <blinov loniir.ru> writes:
  31.08.2010 16:49, Michel Fortin пишет:

 On 2010-08-31 06:16:17 -0400, bearophile <bearophileHUGS lycos.com> said:


 If in generic code T.init is not guaranteed to be an lvalue, as your 
 example shows, isn't it better to disallow (turning it into a syntax 
 error) &T.init in all cases?



 Personally, I'd say the code should check if T.init is an lvalue using 
 __traits(compiles, &T.init) or is(typeof(&T.init)) and avoid creating 
 a static variable or temporary when it is. This optimization of course 
 depends &T.init not being a syntax error.




struct S
{
int a;
 property static S init() { return S(10); }
}

Or even

struct S
{
 property static void init() {}
}

Personally I agree with bearophile, but maybe the code such as above 
should be forbidden as well, and for other builtin properties too?
Aug 31 2010